מצגת לאנשי האיגוד הישראלי להנדסת מערכות מפגש 1 19 במאי 2015 עוזי אוריון

הנדסת מצגת לאנשי האיגוד הישראלי להנדסת מפגש 1 19 במאי 2015 מבוא להנדסת מורכבות אלביט אלקטרו-אופטיקה אלאופ חבר הנהלת האיגוד הישראלי להנדסת, לשעבר-נשיא האיגוד מרצה בטכניון ובמכון הטכנולוגי חולון The whole of Systems Engineering is nothing more than a refinement of everyday experience after Albert Einstein תוכן 1

זו הנדסת? הנדסת 2

וזה מהנדס? הנדסת 3

1.1 מבוא 1.2 תהליכי פיתוח 1.3 נושאי מפגש מס' 1 1.2.1 תהליך פיתוח גנרי 1.2.2 מודלים סדרתיים בהם מפותח דגם עיקרי יחיד 1.2.3 מודלים סדרתיים הכוללים דגמים מוקדמים 1.2.4 מודלים איטראטיביים ניהול דרישות 1.3 1.3.1 מבוא 1.3.2 איסוף צרכי בעלי העניין 1.3.3 תפקודיים ואיתורם 1.3.4 ניתוח הדרישות 1.3.5 מבוא לניתוח תפקודי 1.3.6 תרגום צרכי בעלי העניין לדרישות ניהול דרישות 1.3.7 1.3.8 1.3.9 1.3.10 1.3.11 1.3.12 1.3.13 )המשך( כתיבה נכונה של דרישות סיווג הדרישות הכנת מסמך הדרישות וסקר SRR מדרישות למפרטים Quality Function Deployment (QFD) רידוד הדרישות הכנת המפרטים הנדסת 4

הנדסת 1.1 מבוא 5

למה צריך את זה? ה מורכבות יותר ורב-תחומיות, עם TTM הולך ומתקצר נדרשת מצוינות טכנולוגית בפיתוח המוצר, בייצורו, בתכונותיו, בהפעלתו וההתקנתו נדרש להבין היטב את צרכי וציפיות הלקוחות ולענות עליהם )במלואם( יש לפתח באופן יעיל מהיר וחסכוני. אין זמן לטעויות יש צורך בתגובה מתאימה לשינויים החלים בשוק, הן מבחינה טכנולוגית והן מבחינת דרישת הלקוחות דגמים מוקדמים נדרשים להוכחת הפיתוח והצגת יכולות המוצר בשוק מעבר מהיר, חלק וללא בעיות לייצור מחירים תחרותיים מחייבים עלויות נמוכות, קונספטים יצירתיים, תיכון טוב יותר וייצור זול יותר הנדסת הנדסת הופכת להיות שם המשחק 6

7 האתגר המערכתי מספר ה ומורכבותן הולך וגדל בכל מערכת יש צורך: לנהל manage( )to לתאר describe( )to להבין understand( )to לחזות predict( )to להתפתח evolve( )to להבטיח חוויית משתמש טובה לנהל את דיסציפלינות הפיתוח לאמת ולתקף את התכן V&V( )to לשמור על בטיחות ובטחון ( to ) keep safety & security לתכן ולבנות ( and to design Implement ) במשאבים סבירים של זמן כסף מאמץ )משאבים אנושיים( ניהול סיכונים הנדסת לתקשר עם הסביבה ו חיצוניות to communicate with the ( )environment and other systems לייצר manufacture( )to לבקר control( )to להתקין install( )to להפעיל operate( )to לתחזק maintain( )to לאבחן תקלות diagnose( )to לתקן repair( )to לנהל תצורה configure( )to Source: LAAS-Laboratory for Analysis and Architecture of Systems, Systems engineering 2

משך הזמן מייזום ועד לחדירה לשוק הנדסת G3 G3.5 G4 Source: INCOSE-SE HDBK V3.2.2 Nov. 2011 8

משך פיתוח תוכניות דומות במפעל תעשיתי הנדסת Development Time 36 Months 24 Months 12 Months 1984 1988 1992 1996 2000 2004 2008 2012 2016 Year 9

הנדסת System Specifications דילמת מהנדס המערכת: סיבוכיות ושילוב Trade Studies Design Calculations Function Lists Open Action Items Risk & Configuration Management Stakeholders' Requirements Traceability Data Graphical Data Source: David Long - Essential Model-Based Systems Engineering, Vitech 2015 10

שיעור ההצלחה בפרוייקטים )תוכנה( הנדסת Failure: Project canceled Challenge: Restarts Cost Overruns Time Overruns Content Deficiancies Success: Project finished on time, on budget with full funcionality Average 2002-2010 2010 2006 Project Success is Rare Failed 21% 19% Challenged 42% 46% Succeeded 9% 49% 42% Agile 29% 57% 14% 2012 18% 43% 39% 37% 35% Waterfall 2004 18% 53% 2009 29% 2002 15% 51% 34% 2009 2000 23% 49% 28% 1994 16% 53% 31% Source: Extreme Chaos, The Standish Group International, Inc. 1994, 2000, 2002, 2004, 2006, 2009, 2013 11

סיבות להצלחה או קשיים בפרוייקטים הנדסת Project Success Factors 1. Executive Management Support 2. User Involvement 3. Optimizing Scope 4. Clear Statement of Requirements* 5. Skilled Resources 6. Project Management Expertise 7. Agile Process 8. Clear Business Objectives 9. Emotional Maturity 10.Realistic Expectations 11. Standard Tools & Infrastructure 12.Realistic Expectations** 13.Smaller Project Milestones** 14.Formal Methodology* Project Challenged Factors 1. Lack of User Input* 2. Incomplete Requirements & Specifications* 3. Changing Requirements & Specifications* 4. Lack of Executive Support* 5. Technology Incompetence 6. Lack of Resources* 7. Unrealistic Expectations* 8. Unclear Objectives* 9. Unrealistic Time Frames* 10.New Technology** Source: Chaos Report, The Standish Group International, Inc. 2013, 2012, 2004*, 1995** 12

סיבות להצלחה או קשיים בפרוייקטים הנדסת 13

משך פיתוח לעומת תיכנון הנדסת 14

חיזוי טכנולוגי של PC משנת 1954 הנדסת 15

טיפוסים של מהנדסי הנדסת מהנדס מערכת מנהל טכני סגן מנהל המחלקה מנהל המחלקה מהנדס מערכת חדש מהנדס מערכת וותיק 16

דרישות בעלי העניין ה אי הבנת הדרישות וחשיבותן היחסית לכל בעלי העניין אי הקפאת הדרישות במועד בו שינויים בהם לא גורמים נזק לפרוייקט שימוש של כל המשתתפים בבסיס נתונים לא מעודכן מצבים של חוסר יכולת גידול של המערכת עקב השתנות הסביבה המערכתית אצל הלקוח אי בהירות תהליך הנדסת המערכת קונספט לא אופטימאלי לא נבדקו באופן רציני כל האפשרויות הרלוונטיות אי קיום קריטריונים נכונים להחלטה תהליך לא נכון של בחינת כל אפשרות )כולל סימולציות( חוסר ניהול טכני חוסר מנהיגות ואי קבלת החלטות נכונות בזמן בחירה לא נכונה של אנשים, אי האצלת סמכויות נכונה ומחסור בדרישת תפוקות נכונה מהדרגים המתכננים המנעות מקביעה נכונה של נקודות העבודה במקרה של פשרות וניהולן הנדסת 17

ה תכנון מאוחר של תהליך האינטגרציה אי זיהוי הקשרים הלוגיים וה של כל אחד מהם הכנת תשתיות בזמן מאוחר מדי תיכון לא מתאים לאינטגרציה הגעת חלקים במצב של חוסר בשלות תכן המתאימה לאינטגרציה חוסר יכולת ביצוע בדיקות בשטח אי הפרדה בין משתנים אי הכנת כל החומר הנדרש )הוראות, סימולציות, תכנון תהליכים( מראש חוסר תכנון ללו"ז הגעות המתאים לאינטגרציה אי עמידה בלו"ז אי מניעת עבודה חוזרת הנובעת מאי בשלות התיכון קונפיגורצית מוצר לא ברורה בכל רגע שמירה על בסיס נתונים לא משותף ולא מעודכן אי ניהול צוות וחוסר במוטיבציה גבוהה הנדסת 18

והתוצאה הנדסת 19

הגדרת הנדסת הנדסת היא דיסציפלינה שמתרכזת בתכנון ויישום המערכת השלמה )להבדיל מחלקיה(. זה כרוך בבחינת הבעיה בכללותה, תוך לקיחה בחשבון את כל ההיבטים וכל המשתנים הנוגעים להיבטים הטכניים והחברתיים )Manual, definition contributed by Simon Ramo הנדסת היא תהליך איטראטיבי של סינתזה, מהכלל אל הפרט, פיתוח ותפעול של מערכת עולם אמיתי, שמספק את כל דרישות המערכת, באופן קרוב לאופטימאלי ( of Howard Eisner,Essentials Federal Aviation Administration [USA], Systems Engineering ( )Project and Systems Engineering Management גישה בין תחומית )interdisciplinary( ואמצעים המאפשרים מימוש מוצלח של. הנדסת מתמקדת בהגדרת צרכי בעלי העניין, והתפקודיות הדרושה, מוקדם בתהליך הפיתוח, תיעוד הדרישות ומימושם ע"י סינטזת תכן ואימות המערכת, מתוך ראית ה הכוללת: תפעול, מחיר ולו"ז, ביצועים, אימון ותמיכה, בדיקות, ייצור וגריטה. הנדסת מתייחסת הן לצד העסקי והן ל הטכניים של בעלי העניין, במטרה להבטיח את איכות המוצר שעונה על צרכי בעלי העניין ( Engineering?, INCOSE, What is Systems )14 June 2004,http://www.incose.org/practice/whatissystemseng.aspx הנדסת 20

מערכת מהנדס הגדרות הנדסת שילוב של מרכיבים הפועלים יחדיו על מנת לבצע או משימות מוגדרות מראש. קבוצה של מרכיבים, תתי או הרכבות שמבצעות מטלה מוגדרת. המרכיבים כוללים מוצרים )חומרה, תוכנה, קושחה(, תהליכים, אנשים, מידע, טכניקות, אמצעים, שירותים ומרכיבים תומכים אחרים ( INCOSE-Systems )Engineering Handbook V3.2.2 Nov. 2011 מערכת היא מעשה ידי אדם, שנוצרה ומשמשת לספק מוצרים ו/או שירותים, בסביבות מוגדרות לתועלתם של משתמשים ובעלי עניין אחרים. מערכת כזו יכולה לכלול מרכיב אחד או יותר הבאים: חומרה, תוכנה, נתונים, אנשים, תהליכים, )כמו למשל תהליך מתן שירות למשתמשים(, נהלים )כמו הוראות הפעלה(, מתקנים, חומרים ודברים טבעיים. אלו נחשבים למוצרים או שירותים )ISO/IEC 15288:2008(E)( מהנדס שהוכשר והתנסה בתחום של הנדסת )INCOSE-Systems Engineering Handbook V3.2.2 Nov. 2011( מערכת מורכבת מערכת שאין לחזות התנהגותה מרכיביה על פי התנהגות על פי אריק הונור 21

הנדסת )System of Systems( קורס הנדסת מערכת של Source: ISO/IEC 15288:2002, p. 53, Figure D 1 22

מערכת הנדסת אנשים תהליכים מוצרים System Breakdown Structure Family of Systems System of systems System Elemnts/Segments Subsystems Assemblies Components מערך תעבורה מערך תעבורה אווירית מטוס נוסעים מערכת ניווט GPS אנטנה כיסוי אנטנה על פי IEEE-STD 1220-2005 Subcomponents Parts Subassmblies Subcomponents Parts Elemnts of the system may include hardware, software and humans dependant on the system definition 23

משפחת )Family of Systems( מערך ( of System )Systems מערכת *)system( אלמנט או מקטע *)element/ segment( תת-מערכת *)subsystem( הרכבה *)assembly( תת-הרכבה *)subassembly( רכיב חלק *)component( *)part( הגדרת רמות מרכיבי המערכת קבוצה של מערכים בעלי קשר תפקודי מוגדר הנדסת מספר מקושרות ביניהן, שפועלות להשגת יעד מוגדר שילוב קבוצת אלמנטים, מקטעים ו/או תתי-מערכת שנועד לבצע יעד מוגדר מוצר, שרות או יכולת עיקריים של המערכת. המונח נמצא בשימוש רחב, אם כי אפשר להשתמש בתת- מערכת במקום מקטע או אלמנט שילוב של הרכבות המבצע פונקציה נפרדת בבירור כמו לדוגמה תקשורת, אלקטרוניקה, מבנה או בקרים קבוצה משולבת של חלקים או רכיבים המרכיבה חלק מוגדר בתת-מערכת, כמו לדוגמה הזרקת דלק במנוע קבוצה משולבת של חלקים או רכיבים המהווים חלק מוגדר היטב של הרכבה פריט מוגדר המורכב ממספר חלקים הרמה הנמוכה ביותר של פריט מוגדר *על פי INCOSE-Systems Engineering Handbook V.2.0 July 2000 24

טרום חוזה-מ' מוצר זיהוי בעלי עניין תאור ה כימות ה חוג הדרישות נו... אז מה זה הנדסת? הגדרת הדרישות זיהוי צרכי בעלי העניין ניתוח התפקודים ניתוח סביבת המערכת הגדרת/ניתוח דרישות חוג המערכת הגדרת פתרונות איזון דרישות נוגדות חקר ביצועים וניתוח חלופות פתרון ניהול טכני תכנון התהליך הפיתוח הפעלת הדיסציפלינות פיתוח הצוות והכלים בקרת התהליך הטכני הנדסת הערכתם וגיבוש קונספט הגדרת מפרט הפיתוח הקצאת מפרטים למרכיבים מימוש המערכת חוג התיכון הגדרת מרכיבי המערכת מימוש מרכיבי המערכת שילובים, בדיקות, אישור הערכות והעברה לייצור תמיכה בלקוח הערכת הפתרון הטכני ניהול הדרישות והמפרטים ניהול שינויים ותצורה אימות ותיקוף המערכת רישוי המערכת בעקבות אריק הונור 25

בקיצור... הנדסת 26

שילוב ה- ilitis בפרוייקט מהנדס המערכת צריך לשלב מספר נושאים נוספים בעת ביצוע התוכנית: אמינות )Reliability( - ההסתברות שמוצר או מערכת יתפקדו )יעמדו במפרטים( בפרק זמן מוגדר בתנאי פעולה מוגדרים זמינות )Availability( תחזוקתיות )Maintainability( ביצוע התחזוקה המתוכננת - הסבירות שהמערכת תתפקד במלואה בזמן הצורך המבצעי בטיחות ( )Safety הנדסת אנוש Engineering( )Human Factors - תכונת התיכון העוסק בקלות, דיוק בטיחות וכלכלת - מניעת פגיע ות והקטנת הסיכויים שעלולים לגרום להם בתהליך התיכון והפעלת המערכת יחד עם החומרה והתוכנה ייצוריות המערכת בדיקתיות והאינטגרציה )Produceability( - )Testability( שירותיות )Serviceability( עקיבות )Traceability( - ותהליכי בדיקתם - - שילוב נכון של גורמי האנוש - תכונת תיכון שמסייעת להקל ולהוזיל את ייצור והרכבת יכולת המערכת להיבדק בהתאם לצרכי ההרכבה, התחזוקה יכולת המערכת להיות ניתנת לשירות קשירת הדרישות והמפרטים ברמות השונות למרכיבי המערכת הנדסת 27

הצלחת הפרוייקט וההשקעה ב- SE הנדסת Traditional Design Risk System Design Detailed Design Product Integration Test Time System Thinking Design Saved Time/ Cost Risk Time לפי SECOE 01-03 INCOSE 6/2004 28

ערך הנדסת המערכת בסיום המחקר הנדסת R 2 =0.794 Eric Honour: Sizing of SE Activities to optimise Return on Investment 2011 33

השפעת שינויים על משך ועלות הפיתוח הנדסת 38

Cumulative Percentage Life Cycle Cost קורס הנדסת הנדסת 100% 90% 80% התפתחות העלויות בפרויקט בטחוני טיפוסי 75% 85% 95% x500-1000 Operations Through Disposal 70% 60% 50% 40% 30% 20% 10% 0% Committed Costs x1 Concept Phase 8% 50% x3-6 Preliminary Design Phase Full Program Expenditures x20-100 Prototype Development 11% 24% Time Integtation/ Test Phase 50% 100% לפי University, 9/1993 Defense Acquisition By the time system level design is complete, 85% of the costs have been committed and the cost to extract defects goes up exponentially 39

הנדסת Late Discovery of Problems Requirements Engineering Sources: System Design 80% of accidents due to operator error High recertification cost of design error 70% corrections requirements leads and to 75% of operator 80% late time error spent 70% system interaction errors in work-arounds discovery at high repair cost Software Architectural Design Component Software Design Rework and certification dominates development cost 70%, 3.5% 1x NIST Planning report 02-3, The Economic Impacts of Inadequate Infrastructure for Software Testing, May 2002. D. Galin, Software Quality Assurance: From Theory to Implementation, Pearson/Addison-Wesley (2004) B.W. Boehm, Software Engineering Economics, Prentice Hall (1981) 10%, 50.5% 16x 20-100x 20%, 16% 5x 3-6x Unit Test 20.5% 0%, 9% 40x 500-1000x Integration Test System-level fault propagation due to incomplete/inconsistent requirements and mismatched assumptions. 110x System Test Acceptance Test Delivery delays not known until late into project schedule Where faults are introduced Where faults are found The estimated nominal cost for fault removal INCOSE 2010 40

Effectiveness of system evaluation קורס הנדסת שלבים בהערכת המערכת לאורך מחזור החיים הנדסת System test & evaluation requirements defined Evaluation using design workstations and analytical models (CAD, CAE, CAM, CALS) Analytical Evaluation of engineering and service test models, system competencies, breadboards, mockups, rapid prototyping System analyses, breadboards, mockups, rapidprototyping Evaluation of prototypes and engineering models (production samples) Performance tests Environmental Qual. Structural tests Reliability Qual. Maintainabilty DemVal Support equipment Personnel test & eval. Production models evaluated at designated test sites System qualification Formal test & demo Field and operational tests Maintenance & availability formal tests ILS verification Continuous evaluation of the system in operational use Mission profile evaluation Reliability, maintainabilty and availability verification Spare part level and personnel level evaluation Changes and improvements evaluation Conceptual Design Preliminary System Design Detailed Design & Development System life cycle Production and/ or Construction System Utilization & Life-Cycle Support Source: Test and Evaluation, Institut für Computertechnik, University of Wien 41

ריבוי תפקודים מיותרים במערכת הנדסת 42

הנדסת סיכום המבוא 43

ללא תלות במספר הדיסציפלינות האתגר הנדסת בעת הכנת הצעת מחיר יש להתייעץ עם כל הגורמים הרלוונטיים, לגבש מענה אפקטיבי ומתואם, ולקבל מחויבות של כל הגורמים בעת לימוד דרישות בעלי העניין והכנת מפרטי הפיתוח, יש לבדוק את האספקטים השונים הרלוונטיים לכל התחומים התכן המערכתי צריך לקחת בחשבון את כל אחת מהדיסציפלינות על מנת לתת מענה אופטימאלי. יש לקבוע חלוקה מושכלת של דרישות המימוש על ידי חישוב מפורט של תקציבי הפרויקט. קביעת נקודות העבודה )Trade-offs( תתבצע תוך בחינת היכולת וההשפעה הכלכלית של כל אחד מהתחומים הטכניים ניהול נקודות העבודה במהלך התכן המפורט חייב להיות דינאמי תוך מתן מענה נכון לבעיות של כל אחת מהדיסציפלינות תכנון השילובים וניהולם מהווה אתגר. כך גם תיאום ברמות בשלות המרכיבים בכניסה לתהליך תכנון תחזוקה שכולל אספקטים של דיסציפלינות רבות ההערכות למעבר לייצור כולל פעילות רב-תחומית מקבילה 44

בעיות אופייניות בהנדסת ידיעת התנהגות מרכיבי המערכת אינם מספיקים לחיזוי התנהגות המערכת מוצר מורכב שנועד לפתור בעיות קשות ריבוי דיסציפלינות טכנולוגיות המשלבות חמרה, תוכנה, משתמשים, שרות, ותמיכה קרוב לאינסוף אפשריות של שיקולי בחירה בין רכיבים שונים אינטראקציות בלתי צפויות רבות חלוקת המשימות בין הדיסציפלינות כרוכה במגעים רבים, מו"מ ופשרות בעיות קשות נחשבות לעיתים בטעות כנפתרות בקלות בעזרת תוכנה קיימות הפרעות הדדיות עקב אי הבנה בין הדיסציפלינות ההנדסיות ה צריכות להיות מתוכננות לפעול שנים רבות בסביבה משתנה. מרובות מגדירים, מפעילים וצרכנים נדרש מענה ל דינאמיים של הלקוחות שילוב כלים במקביל הנדסת 45

קשיים בהגדרת יעדי המערכת שינויי דרישות במהלך אפיון המערכת יש ל יצ פ ות התפתחות במרכיבי מערכת )חומרה, תקשורת( או התיישנות רכיבים, לאורך חיי המערכת הנדסת 46

כשלון... הנדסת 47

והפקת לקחים הנדסת 48

כמה שאלות למחשבה... איך מקצרים את משך הפיתוח של מערכת מורכבת? הבנת ה והגדרות ניהול דרישות ניהול סיכונים ארכיטקטורה קונספטים אימות והוכחת כשר תיקוף מלא הנדסת 49

הנדסת 1.2 תהליכי פיתוח 50

הנדסת 1.2.1 תהליך פיתוח גנרי 51

הנדסת Need User Requirement Analysis SE Model Top-Level flow Diagram Operational Definition Requirements קורס הנדסת מה חסר? Functional Definition Functions Physical Definition (Design) System Model, Design Documents Design Verification Solution(s) Source: Alexander Kossiakoff, William N. Sweet, Samuel J. Seymour, Steven M. Biemer System Engineering Principles and Practice, 2003 52

תהליך מפושט של פיתוח מערכת הנדסת Source: APL - A Practical Guide to SysML, Elsevier Inc., 2008 53

תהליך הפיתוח בהקשר לחיי המוצר הנדסת Source: H. Stoewer 54

מחזור פיתוח של פרויקט הנדסת Initiation Requirement Preliminary Elicitation Design System Planning Concept Design Detailed Design Implementation & Integration Transition Into production Operation & Maintenance Disposition Go No go Review System Requirement Review system Design Review Preliminary Design Review Critical Design Review Alpha Readiness Review Production Readiness Review First Article Inspection 55

הנדסת Company s PLM A קורס הנדסת מוצג באישורה האדיב של חברת אורבוטק 56

ייזום הפרויקט מחזור פיתוח של פרויקט )Initiation( החלטות כלכליות החלטות Go-No Go תכנון ראשוני של הפרויקט הערכה גסה של משך ועלויות ניתוח התהליך השיווקי זיהוי שווקי היעד החלטות על שותפים אסטרטגיים הערכה גסה של היקף מכירות, מחירים, עלויות ורווח זיהוי גורמי עלות עיקריים בייצור ובפיתוח זיהוי ראשוני של הסיכונים העיקריים החלטות על צורך בחקרי היתכנות והשלמות טכנולוגיות מיסוד הרמה הגבוהה של הפרויקט וקביעת מהות הפרוייקט ויעדיו הנדסת זיהוי בעלי העניין ואיסוף הדרישות הבנת זהותם של בעלי העניין החיצוניים ואיסוף צרכיהם ניתוח צרכי המידע של המשתמש הסופי ניתוח מערכתי זיהוי הבעיות העיקריות בפרוייקט ודרכים לפתרונן פירוק המערכת לחלקים, על פי ההגיון, וניתוחם ניתוח יעדי הפרוייקט ועדכונם ניתוח של מה שצריך לפתח הגדרת דרישות בעלי העניין )בתאום איתם( קביעת יעדי פרויקט מעודכנים לתפקודים מוגדרים, תפעול התוצר והשימוש המיועד Kick-Off Meeting - KOM 57

58 תכנון הפרויקט מחזור פיתוח של פרויקט )Planning( תכנון מפורט של הפרוייקט - Project Management Plan PMP Systems Engineering SEMP Managent Plan - Work Breakdown Structure WBS Organizational Breakdown OBS - Structure לוח זמנים מבנה תקציבי מפורט אבני דרך דרישות )בעלי העניין( עיקריות ממשקים חיצוניים סריקת Intellectual Properties ניתוח הרכש ובעיותיו )ספקים, עלויות( ניתוח התשתיות הדרושות וקביעת הפערים ותוכנית לסגירתם זיהוי צורך בדיסציפלינות לא מקובלות Engineering( )Specialty סוגיות )בעיות שפתרונן דורש מעורבות של רמות גבוהות יותר בארגון( מיצוי הדרישות הנדסת שימוש בצוותים )או נציגים( של הלקוח והאירגון המפתח והתקשורת ביניהם לצורך פירוט ועידון הדרישות הבנת הדרישות קביעת הסכמות לגבי דרך אישורן ניתוח תפקודי והבנת הדרישות המערכתיות שלב זה חשוב מאחר ולעיתים מתגלות, בשלבים מאוחרים מדי, בעיות תקשורת או חלוקי דעות על דגשים ועדיפויות עם הלקוח שגורמות לשגיאות תכן או שגיאות או אי הסכמה בתיקוף שלהן )validation( System Requirements Review SRR

A Company s Documentation Phase 4 הנדסת קורס הנדסת מוצג באישורה האדיב של חברת אורבוטק 59

60 תיכון מערכתי מחזור פיתוח של פרויקט ניתוח תפקודי, חישובי מערכתי וחקר ביצועים להבנת משמעויות הדרישות. ניתוח התפקודים, התפעול ותכונות המערכת, ותרגום ההישגים הנדרשים ותהליכי הבדיקה, כך שיאפשרו את הפעלת כל הגורמים המפתחים קביעת ה- Trade-offs בין דרישות סותרות יצירת חלופות קונספטואליות באופן יצירתי וניתוח החלופות למימוש אופטימאלי של דרישות בעלי העניין. בחירת הקונספט המתאים ביותר הגדרת המפרטים המערכתיים חלוקה ראשונית למרכיבים כמו מודולים, מכלולים, כרטיסים אלקטרוניים, כבלים, אריזות וכו'. System Design Review - SDR הנדסת תיכון ראשוני קביעת הקונספטים הדיסציפלינאריים חלוקה של המערכת למרכיביה )מודולים, מכללים, כרטיסים אלקטרוניים, כבלים, אריזות וכו'(. הגדרת מפרטי מרכיבי המערכת הגדרה סופית של הממשקים החיצוניים ותכנון מפורט של הממשקים הפנימיים תכנון מפורט של תהליך האינטגרציה המערכתית קביעת תהליך בקרת התצורה של הפרוייקט זיהוי וניהול מפורט של סיכוני הפיתוח ביצוע, אם נדרש, של דגמים מוקדמים להורדת סיכונים קביעת דרישות הבטיחות Preliminary Design Review - PDR

61 פיתוח מלא )FSD( מחזור פיתוח של פרויקט פיתוח הדגם ההנדסי שמייצג את המוצר בייצור., המתקנים, המכשור קביעת הכלים וטכנולוגיות הייצור שנדרשים לייצור סידרתי של החלקים והמערכת קביעת תהליכי הבדיקה בדיקת התאמת המערכת לסביבת העבודה המתוכננת ניתוח רובוסטיות המערכת בתנאי הסביבה שהוגדרו לה ניתוח התאמה מכנית ותפקודית לדרישות ולסביבת העבודה ניתוח השתלבות המערכת בסביבה האלקטרומגנטית ו"חיים בצוותא" עדכון תכנון תהליך האינטגרציה ניהול תצורה ושינויים בניית דגמי הורדת סיכונים או קביעת פרמטרים תיעוד מלא של תוצרי הפיתוח והשלמת מסמכי הפיתוח Critical Design Review - CDR יצור ובניית הדגמים הנדסת רכש, ייצור, ובדיקות החלקים הנדרשים לדגמים ההנדסיים רכש או ייצור הכלים והציוד שנדרש להרכבת הדגמים, בדיקתם ולביצוע יעיל של תהליכי האינטגרציה הכנת הוראות הרכבה הכנת מערכתי בדיקה סימולציות ודפי תוצאות עם בתוצאות הבדיקה החזויות הרכבת מרכיבי המערכת )כרטיסים, מכללים, כבלים, אריזות( ובדיקתם )המלאה( ע"י המפתחים ניהול שינויים ותצורה הפעילות מושלמת כאשר כל מה שנדרש לאינטגרציה מערכתית נמצא ונבדק Integration Readiness Review - IRR

62 מחזור פיתוח של פרויקט אינטגרציה ובדיקות מערכתיות המרכיבים משתלבים ונבדקים ברמות המערכתיות השונות סוגי הבדיקות בדיקות אינטגרציה ( Integration )testing בדיקות מערכתיות testing( )System בדיקות התאמה וביצועים ( & Conformal )Performance testing בדיקות תפקודיות testing( )Functional בדיקות לאיתור חוסר התאמה )Defects( בדיקות עמידה בתנאי סביבה )Environmental condition testing( בדיקות הדירות ורובוסטיות )Repeatability & robustness testing( בדיקות נכונות מעברי הנתונים ( set Data Load ( בדיקות עומס חישובי.)testing )Test בדיקות רגרסיה testing( )Regression : -Site בדיקות המבוצעות במעבדות המפתח, של המענה שנותנת המערכת לדרישות בעלי העניין, תוך הפעלת סימולציה של סביבת עבודה מלאה אינטגרציה )המשך( הנדסת לעיתים מבצעים בסוף התהליך בדיקות קבלה מול הלקוח ( User )acceptance testing Test Readiness Review TRR Alpha Readiness Review ARR אימות ותיקוף המערכת תהליך האימות והתיקוף נמשכים, למעשה, במקביל ולאורך כל מחזור חיי הפיתוח בדיקות האימות נועדו לבדוק את העמידה בדרישות בעלי העניין ונכונות התפקוד המערכתי, כולל תנאי סביבה, תאלמ"ג, ניסויי בטיחות וכו'. בדיקות התיקוף מיועדות לבדוק את עמידת המערכת בצרכי הלקוחות ומתן מענה לתרחישי הייחוס וסביבת הפעולה של הלקוח.

ייצור, תפעול ותחזוקה מחזור פיתוח של פרויקט הכשרת המערכת לפעולה אצל הלקוח,FAI( -site,fca,pca,catp,matp,testing )Commissioning העברת המוצר לייצור, במקביל לתהליך האינטגרציה ובהתאם ללקחים שנמצאו שם הכנת והעברת שרטוטי ייצור, רשימות החלקים לרכש ולייצור, החלטות עשה/קנה קביעת קבלני המשנה למרכיבי מערכת או לחלקים מיסוד תהליכי הייצור, כלי הייצור, ההרכבה והבדיקה הכשרת ואימון המייצרים והמרכיבים ייצור סדרת ייצור ראשונה להוכחת יכולת הייצור ועדכונה קיום סקר מוכנות לייצור -PRR Production Readiness Review מעבר לרכש וייצור שוטף ייצור, תפעול ותחזוקה )המשך( הנדסת הקמת מערך תחזוקה ותמיכה בלקוח במקומות בהם מתוכנן ייצור כמותי, נדרש לבצע פעילות של הוזלת המוצר על ידי שימוש בטכנולוגיות יותר זולות, תוך השקעה יותר גדולה בתשתיות. ביצוע שיפורים ושינויים כנדרש )בקרת תצורה!( גריטה )Disposition( שלב סוף החיים הכנת מסמכי גריטה )לפני תחילת הפצת המוצר( פירוק טיפול בחומרים מסוכנים מיחזור שימוש חוזר )Reuse( טיפול בפסולת התעשייתית 63

תוכנה נושאים חריגים לעיתים קרובות מתקדמים עם התוכנה בפיגור של שלבים עקב הצורך לקבוע את סוגי המחשבים )PDR( לפני שניתן לקבוע את קונספט התוכנה יש להתייחס למצב זה בזהירות מאחר והוא עלול לגרום לחוסר זמן בבדיקות התוכנה רכש תהליכי ההרכשה עלולים להימשך זמן רב עקב גורמים שאינם בשליטת הפרוייקט,LLI( רשיונות ייצור, זמני ייצור ארוכים אצל היצרן, אי עמידת היצרן בדרישות וכו'( יש להיערך למצבים הללו טוב ככל האפשר, לפני שהם גורמים ל שפתרונה מזיק לפרויקט הנדסת 64

הנדסת?)SDLC( קורס הנדסת מה זה מחזור חיי פיתוח קבוצה שלמה של פעילויות הדרושות לאפיון, תיכון בניית ובדיקת שיטת ניסוי וטעייה )תהייה?( Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance http://www.cs.uwlax.edu/~zheng/cs741summer05/lecture2.ppt 66

ב 4 ב 3 קורס הנדסת האם מחזור? הנדסת מחזור החיים של רק"מ שונה מזה של טיל. הרק"מ נועד לשימוש ממושך ועובר שינויים והשבחות לעיתים בהתאם לדרישות הטכנולוגיות ושדה הקרב. הטיל נועד לאחסנה לאורך מרבית חייו, לעיתים עובר טיפול או שינוי ומשתמשים בו רק פעם אחת, במשך זמן קצר )בד"כ(. האם באמת יש מחזור? אחרי "מרכבה 1" פותח הטנק "מרכבה 2". אחריו פותחו "מרכבה 3", ","',4" "' וכו'. אחרי ה- Iphone פותח ה- IPhone2 ואחריו,Iphone 3 Iphone 5,Iphone 4 וכו' אחרי,PC-XT פותח,PC-AT אחריו פותחו,IBM Junior,IBM Thinkpad תואמי,PC מחשבים אישיים, טבלטים וכו' אחרי Window 3 פותח ME,2000,98,95,Windows NT...8,7,Vista,XP, 67

מודלים של מחזור חיי הפיתוח מודלים של מחזור חיי פיתוח המערכת System Development Life (SDLC) Cycles מבוססים על 3 גישות עיקריות: מודלים סדרתיים בהם מפותח דגם עיקרי יחיד בסוף תהליך הפיתוח Waterfall Model V Model מודלים סידרתיים המבוססים על הורדמוקדמת של סיכוני פיתוח על ידי פיתוח מהיר של דגמים ושכלולם עד לקבלת המוצר הסופי )Prototyping Models( Throwaway Prototyping Model Brugge Model Incremental Development Evolutionary Prototyping Model מודלים איטרטיביים Spiral Model Lean-Agile SE,Agile SE הנדסת 68

הנדסת 1.2.2 מודלים סידרתיים הם ד ב מפותח דגם עיקרי יחי 69

"מפל המים" הנדסת 1.2.2.1 מודל Requirements מי שולט בדרישות? מי מחליט על תחילת הפעולה הבאה? מי מתכנן את המוצר? Design מתי מורידים סיכוני פיתוח? איך נבחנת התאמה לדרישות בעלי העניין? Detailed Design איך ממקבלים תהליכים? Implementation Testing & Documentation ATP הרעיון: כל פעילות שמסתיימת מפעילה את הפעילות שבאה אחריה המודל המיושן והפחות גמיש שבין המודלים של מחזור חיי הפיתוח מתאים לפרוייקטים בהם מפרטי הדרישות וממשק המשתמש הינם בעלי סיכון נמוך ואילו יכולת הערכה וניהול הלו"ז והתקציב הינם בסיכון גבוה 70

הנדסת Operating Environment User needs & Expectations / הנדסת Set Rqmnts Functional Decomposiion Functions System System Design Specifications Costs & schedule rqmts Detailed Specifications Component Specifications 1.2.2.2 מודלי V קורס הנדסת - תהליכי דרישות מערכת Requirements Detailed Design Feasability Concepts Preliminary Design Top Level Design Designs Prototype Construction Subsystem Integration &Testing Unit Integration & Testing User Acceptance Testing System Integration & Testing Site / System Validation in its Environment α site / Qual. Testing Production Verification & Validation Transition for Production Production processes & technologies System Logistic Support, Maintenance & Update Production System Disposal פשוט ומובנה המערכת מתחילה לעבוד מאוחר רגיש לשינויים בדרישות Verification Validation 71

הנדסת 1.2.3 מודלים סדרתיים הכוללים דגמים מוקדמים 72

הנדסת Saw tooth Model (Brugge Model) 1.2.3.1 Requirements Analysis 1st Prototype Black Label 2nd Prototype Pre Red Label Qualification Test Integration Test Unit Test System Design Program Design Red Label Model הורדה מוקדמת של סיכוני הפיתוח העיקריים עלול לדרוש יותר ממחזור תיכון אחד עלול ליצור מצג שוא אצל הלקוחות וההנהלה לגבי התקדמות צהירה בפרויקט התכן הגרוע של הדגמם המהירים עלול לזלוג לתכן הסופי 73

הנדסת 1.2.3.2 מודל Prototyping קורס הנדסת Source: Alavi M.- An Assessment of the prototyping approach to information system development, Communications of the ACM, 27(6), 556-563, 1984 74

1.2.3.2 מודל Prototyping 75 יתרונות התפקודים החשובים ביותר נבדקים במועד הראשון האפשרי בעיות טכניות ואחרות מתגלות בשלבים מוקדמים-הקטנת סיכונים עקביות הדרישות נבדקת בכל איטראציה הלקוח יכול לחוש כל הזמן בהתקדמות הפרויקט מאפשר שיתוף פעיל של בעלי העניין משלבים מוקדמים של הפרויקט ניתן להשתמש בדגמים של כל שלב לקבלת יתרונות שיווקיים חסרונות זיהוי קבוצת הדרישות העיקריות בכל שלב הוא תהליך מונוטוני מעייף ומשעמם קביעת עקביות הדרישות בכל איטראציה הינה עבודה חוזרת, משעממת וגוזלת זמן, במיוחד כאשר הדרישות הנוספות אינן קשורות בקיימות. מועדים פרויקטליים קשים להערכה. אין גמר ברור לכל איטראציה. קיימות בעיות "תחזוקה" של הדגמים ותוכניות העבודה התיעוד עלול להיות מוזנח המאמץ של בניית הדגמים עלול להיחשב כבזבוז קשה יותר לתכנון ולניהול דוגמאות הנדסת

הנדסת Time Change Management Evolutionary Prototyping Model User Reqs System Reqs User Reqs System Reqs User Reqs System Reqs Primitive System Development Architectual Components Design Development Integration & 1.2.3.3 קורס הנדסת פחות רגיש לשינויי דרישות תכן בשל נדרשים לפחות 3 סבבי פיתוח Operational Systems Verification Intallation & Validation Operations 1 Performance System Development Feedback from System 1 Architectual Components Design Development Integration & Verification Intallation & Validation Operations Final System Development 2 Architectual Design Feedback from System 2 Components Development Integration & Verification Intallation & Validation Operations 3 Gilb, T., Principles of Software Engineering Management, Addison-Wesley, 1988 76

הנדסת Incremental Model 1.2.3.4 User Requirements System Specifications Basic system Additional Feature Additional Feature Architectual Design Component Development 1 Component Development 2 Component Development 3 יציאה מהירה לשוק פחות רגיש לשינויי דרישות ארכיטקטורה בעיתית Integration & Verification 1 Integration & Verification 2 Integration & Verification 3 Operational system Installetion & Validation 1 Operations 1 Installetion & Validation 2 Installetion & Validation 3 Gilb, T., Principles of Software Engineering Management, Addison-Wesley, 1988 Operations 2 Operations 3 Time 77

הנדסת Evolutionary & Incremental Model קורס הנדסת Source: INCOSE Systems Engineering Handbook v. 3.2.2, October 2011 78

הנדסת 1.2.4 מודלים איטראטיביים 79

Prof. Barry Boehm The Spiral Model Detailed Reqs. Functions Definition Cycles Ver. 1 Ver. 2 Ver. 3 Reqs. Concept Prototype Components Integration 1.2.4.1 System Performance System Functionality קורס הנדסת הנדסת המודל הספיראלי דוגמה למודל איטרטיבי פותח ב- TRW ב- 1988 כל איטראציה מחזורית כוללת: הגדרת דרישות ניתוח סיכונים סימולציה, ניתוח השוואתי תיכון, בניה, בדיקות תכנון המחזור הבא )אם יש( Design/Develop 80

The Spiral Model הוגדר ע"י בארי בוהם במאמרו משנת 1988: of A Spiral Model Software Development and Enhancement. איטראציה אופיינית במאמר נמשכת בין חצי שנה לשנתיים כל פאזה מתחילה בתיכון יעדים ומסתיימת בסקר התקדמות ע"י הלקוח )יכול להיות גם פנימי( מאמצי ניתוח והנדסה נעשים בכל שלב של הפרוייקט, עם מבט ליעדי הפרוייקט כולו הנדסת מתוך Wikipedia, May 28, 2007 81

שימושים The Spiral Model המודל נמצא בשימוש בעיקר בפרוייקטים רבי היקף, כמו למשל ה- Future Combat Systems program האמריקני. בפרוייקטים קטנים יותר, קונספט ה- Development Agile הוא אלטרנטיבה עדיפה. יתרונות ההערכות )כמו תקציב, לו"ז וכו'( מתקדמת, מאחר וסוגיות חשובות מתגלות יחסית מוקדם קל יותר לקבל שינויים שנגררים בתהליכים הרגילים דגם פועל כבר בשלבים מוקדמים של מחזור חיי הפיתוח נעשות יותר ראליות ככל שהעבודה דגש על אלטרנטיבות ואילוצים מוביל ל- REUSE בנושאי תוכנה, אפשר להתחיל לעבוד יותר מוקדם בפרוייקט חסרונות עלול להיות יקר בשמוש הצלחת הפרוייקט תלויה מאד בניתוח מוקדם של הסיכונים הנדסת ע"פ http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx From Wikipedia 5/28/07 82

הנדסת 1.2.4.2 תהליכי פיתוח Lean Agile SE 83

מה זה?Lean SE הנדסת שיטה שפותחה כתהליך ייצור בטויוטה ומאומצת ע"י אנשי הנדסת בעולם השיטה ממצה את נושא שיפור הערך ללקוח ומניעת אותם פעילויות או תהליכים שאינם תורמים לערך זה מה זה?Agile SE שיטה שפותחה לפיתוח והנדסת תוכנה ומאומצת על ידי אנשי הנדסת ה בעולם השיטה גורסת שניתן לפתח פרויקטים בצורה איטרטיבית, על ידי חלוקתו למשימות קטנות יחסית שבסופן תפוקות המסופקות בתדירות גבוהה. לשתי השיטות הללו מכנים משותפים רבים ואנו ננסה לתאר כאן תהליך פיתוח שמכליל את שתי השיטות. 84

הנדסת 1.2.4.2.1 מבוא קצר ל- SE LEAN 85

הנדסת Waste of Time and Effort in Product Developmwent Wasted Effort 40% of product development effort pure waste (LAI PD workshop opinion survey) 29% necessary waste (workshop opinion survey) 30% of product development charged time setup and waiting (aero and auto industry survey) 31% value added 29% Necessary nonvalue added 40% pure waste Wasted Time 62% of tasks idle at any given time (LAI detailed member company study) 50-90% task idle time found in Kaizen-type events 38% job active 62% job idle קורס הנדסת Source: Seeing and Improving the Product Development Value Stream, Hugh McManus, LAI Executive Board Presentation, June 1, 2000 Value Added: The external customer is willing to pay for Value Transforms information or material Provides specified performance right the first time Necessary Non-Value Added: No value is created but which cannot be eliminated based on current technology or thinking Required (regulatory, companymandate, legal) Pure Waste: Consumes resources but creates no value in the eyes of the customer If you can t get rid of the activity, it s non-value added but necessary Source: LAI EdNet 86

מהו ערך? הנדסת "ערך" )Value( מוגדר כאבטחת ה )אספקת מערכת שתפעל ללא רבב מבחינה טכנית לאורך חיי המוצר או ה( וסיפוק צרכי וציפיות המשתמשים ושאר בעלי העניין. כלומר השלמת הפיתוח במוצר שעונה לכל צרכי בעלי העניין עם מינימום בזבוזים, מינימום עלויות ולוח זמנים הקצר האפשרי Source: INCOSE Systems Engineering Handbook v. 3.2.2, October 2011 מידת שווי מוצר או שרות ספציפי ללקוח. הערך הוא פונקציה של: התועלת של המוצר לסיפוק צורכי בעלי העניין 1. הקצאת החשיבות היחסית נכונה של ה שסופקו 2. זמינות גבוהה של המוצר כשצריך אותו 3. עלות בעלות נמוכה ללקוח 4. Source: Slack, R, The application of Lean Principles to the Military Aerospace Product Development Process, MIT SM Thesis, Dec 1998 87

מהו בזבוז? מרכיב עבודה שאינו תורם ערך למוצר בעיני הלקוח )מוסיף עלויות וזמן ללא תועלת( הבזבוז מחולק ל- 7 קטגוריות, שמוצגות כאן בסדר יורד של מקרים בפרויקט זמני המתנה עיבוד יתר, עבודה מיותרת ייצור יתר Spec) (Over תחבורה, הובלה, גישה למידע מלאי ועבודות לא גמורות בתהליך( תנועות שלא לצורך פגמים ותקלות לאורך הדרך )מלאי הנדסת כל אחד מגורמים אלו גורר פעילויות מניעה רבות. יש לבחון את העוצמות של כל אחד מהמרכיבים בהקשרי הפרויקט המסוים ובהתאם להחליט על דרכי ההתמודדות עם הבזבוז הנוצר בתהליך 88

89 המתנה עיבוד יתר ייצור יתר, עודף חומר או נתונים תחבורה מלאי תנועות מיותרות פגמים "בזבוזים" הנדסת המתנה למידע, אישורים, חתימות, תכנון סדר פעולות שגוי, חוסר תיאום, עבודה טורית שלא לצורך החלטות וכו' אספקה מאוחרת או שגויה תיעדוף אספקה מוקדמת מדי שלא לצורך רה-אירגון או חוסר אירגון עבודה יותר מהנדרש לקבלת תחילת עבודה עם רזרבות קטנות מדי עבודה על גירסה שגויה של נתונים התפוקה הנדרשת תכן נקודתי מוקדם מדי, שגורם המרות מיותרות של פורמטים או נתונים לאיטראציות מסיביות דרישות לא ברורות או לא יציבות ייצור סידרתי מיותר הפצת יתר של מידע Over spec. המצאת גלגלים יצירת מידע מיותר פיתוח כפול )חוסר ב- Reuse ( התעלמות ידע של ממומחים העברה לא יעילה של מידע מידע לא מתאים כשלי תקשורת, איבוד מידע, האטת התעבורה עקב שיקולי ביטחון חוסר תאימות מידע, פורמט שגוי קשר לא תקין בין מקומות שונים ייצור חלקים או מידע יותר מהנדרש בסיסי נתונים מרובים, שיחזור מידע מסובך ניהול תצורה לא מתאים, הפסקות והתנעות פרויקטים מיותרות תנועות מיותרת לקבלת גישה התערבות ידנית לקיזוז חוסר גישה מידע מופנה לגופים לא נכונים פניות חוזרות למידע עקב אי תגובה חוסר בקרה טכנית או אימות,Recertify,Recalibrate,Rewrite מידע שגוי, לא ברור או לא מדוייק Re-inspect,Retest,Recheck וכו' ע"פ 1.0, Bo-Openhein: Lean Enablers for Systems EngineeringVersion Released February 1, 2009, INCOSE

הנדסת Operations initiates Request for Action Forward To Planning F16 Forward Fuselage BTPSC Forward to Engineerig Log/ Hold in Backlog Engr answer Prepare Planning Change Log/ Hold in Backlog Tool Affected? No Yes Prepare Design Change Forward to Operations Prepare Tool Order Operations Uses Revised Planning Forward to TMP Log/ Hold in Backlog Process Tool Order Forward to Tool Design Log/ Hold in Backlog Prepare Tool Design Change Forward to TMP Log/ Hold in Backlog Forward to MRP Log/ Hold in Backlog Complete Tool BTP Forward to Tool Mfg.. Log/ Hold in Backlog Accomplish Tooling Change Forward to Operations Operations Uses Revised Tool Process Before LEAN Source: Seeing and Improving the Product Development Value Stream, Hugh McManus LAI Executive Board Presentation, June 1, 2000 90

הנדסת F16 Forward Fuselage BTPSC Prepare Design Change Operations initiates Request for Action BTP Integrator Holds Meeting Prepare Planning Change Prepare Tool Design Change (If Applicable) Accomplish Tool Change (If Applicable) Forward to Operations Operations initiates Request for Action Single Piece flow, concurrent engineering, co-location Process After LEAN Source: Seeing and Improving the Product Development Value Stream, Hugh McManus LAI Executive Board Presentation, June 1, 2000 91

הנדסת כמה זמן לוקח באירגון שלך לאשר שרטוט? כמה שרטוטים מייצרים בשנה? מה משמעות של חסכון בשעה אחת בתהליך הזה? 92

לוח הזמנים של מהנדס המערכת )בזבוזים(? הנדסת כתיבת דרישות מצגות נסיעות דיווחים mail ישיבות כמה זמן נטו נשאר לו? על פי צבי מנדלסון 93

ששת עקרונות ה- Lean הלקוח קובע ערך הנדסת צור מערכת של אמון, הערכה וכבוד הדדיים בין כל בעלי העניין החשובים, הקנה מוטיבציה לצוות על מנת לקבל תוצאות מיטביות מפה את זרימת הערך הצעת הערכים חייבת להיות ברורה כבדולח, מהשלבים מוקדמים של התוכנית )מתייחס ללקוחות חיצוניים ופנימיים( שאף לשלמות הכן תוכנית של כל הפעילויות הדרושות למימוש הערכים, מקצה לקצה, בזרימה רציפה, תוך ביטול בזבוזים, תוך שימוש בתהליך הטוב ביותר של קבלת החלטות שפר בקביעות את התהליכים וזהה את כל הליקויים ע"מ ליצור מוטיבציה רכש כבוד לתקנם בשיפור מתמיד לאנשים זה חייב לקרות ללא מעצורים, עבודות חוזרות או החזרות )איטרציות אופטימיזציה לגיטימיות-מותרות( תכנן לזרימת ערך רציפה לאורך זרימתו תן ללקוח למשוך את הערכים צורך/משיכת הלקוח )הפנימי או החיצוני( מגדירה את המשימות ותזמונן Source: Bo Oppenheim, LM University, LA 94

"חוק הזהב" או "למה הלקוח תמיד צודק" הנדסת 95

הנדסת 1.2.4.2.2 מבוא קצר מאד ל- Agile SE תוכנה נמצאת כיום בתחרות בין מהנדסי התוכנה ששואפים לבנות גדולות יותר וטובות יותר חסינות אידיוטים, והיקום שמייצר אידיוטים גדולים יותר וטובים יותר. עד כה, היקום מנצח. ריץ' קוק 96

המנשר לפיתוח תוכנה אג'ילי אנו חושפים דרכים טובות יותר לפיתוח תוכנה תוך עבודה ועזרה לאחרים. אלו הם ערכינו ועקרונותינו: אנשים ויחסי גומלין תוכנה עובדת שיתוף פעולה עם הלקוחות תגובה לשינויים על פני תהליכים וכלים על פני תיעוד מפורט על פני משא ומתן חוזי על פני מעקב אחרי התוכנית הנדסת http://agilemanifesto.org/iso/he/ כלומר, בעוד שיש ערך לפריטים בצד שמאל, אנחנו מעריכים יותר את הפריטים בצד ימין. Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick 97 97

98 98 העקרונות שמאחורי מינשר ה- Agile אנו מכבדים את העקרונות הבאים העדיפות הגבוהה ביותר היא לספק את הלקוח ע"י אספקה מוקדמת ומתמשכת של תוכנה עם ערך שינויים בדרישות מתקבלות בברכה, גם מאוחר בפיתוח. פיתוח זריז רותם אותם ליתרונות תחרותיים ללקוח ספק בתכיפות תוכנות עובדות, כל שבועיים עד כל חודשיים, תוך העדפת קיצור לו"ז המפתחים חייבים לעבוד יחד עם אנשי העסקים על בסיס יומי לאורך כל הפרוייקט בנה את הפרוייקט סביב עובדים בעלי מוטיבציה. תן להם את הסביבה והתמיכה להם הם זקוקים וסמוך עליהם שיבצעו את עבודתם הדרך היעילה והאפקטיבית להעברת מידע אל ובין המפתחים היא בשיחות פנים-אל פנים תוכנה עובדת היא המדד העיקרי להתקדמות תהליכים זריזים מקדמים תיכון בר-קיימא. נותני החסות, המפתחים והמשתמשים נדרשים לתחזוקה בקצב קבוע למשך זמן לא מוגבל תשומת לב מתמידה למצוינות טכנולוגית ותיכון טוב מאיצים את מהירות התהליך פשטות - האמנות של מיקסום העבודה שלא מתבצעת - חיונית הארכיטקטורה, הדרישות והתיכונים הטובים ביותר צומחים מצוותים המארגנים את עצמם במרווחי זמן קבועים, הצוות ישקף איך להיות יותר אפקטיבי, וליישם זאת בהתנהגותו, בהתאם הנדסת http://agilemanifesto.org/principles.html

מה אנחנו בעצם מחפשים תהליך פיתוח מבוסס למידה וקבלת החלטות מבוסס ידע תהליך פיתוח מבוסס בדיקות אספקות מהירות הבטחת איכות מובנית ומוכנות גבוהה לייצור נמצא שעבודה על פרוייקטים קטנים מעלה את סיכויי ההצלחה בפרוייקט הנדסת CHAOS manifesto, 2013 99

Source: INCOSE פרדוקס הידע בפרויקטים יצירתיים, הידע שלנו משתפר ככל שאנו מתקדמים בתהליך הפיתוח במודלים מסורתיים של,SDLC מרבית ההחלטות החשובות )כמו לדוגמה ההחלטה על הקונספט וקביעת ה- LLI (, מתקבלות בשלבים המוקדמים של תהליך הפיתוח, בעת שרמת הידע שלנו נמוכה מדידות סימולציות מדידות סימולציות אנליזות אנליזות הנדסת Knowledge Level Goal Hazardous Area Goal 100% Design Freedom Requirements System Design Preliminary Design Design Readiness Integration Readiness Production Readiness 100

הנדסת קורס הנדסת השואה בין Lean Lean קשר קרוב עם בעלי העניין ושקיפות מלאה מבוסס על ערך ללקוח ביטול בזבוזים מונחה בתהליך הקטנת הרגישות ע"י שימוש בדרישות הרלוונטיות לעכשיו תוצרים קטנים ומהירים מאפשרים לימוד מתמיד העדפת ניסויים על ניתוחים מתבסס על ניתוח זרימת הערך והחלקתו ו- Agile Agile 101 סיפוק צרכי בעלי העניין ערך בזבוז אספקה מתמשכת של תוצרים בעלי ערך מבוסס על ערך הלקוח -- שינוי דרישות איטראציות קצרות העדפת 'ברזלים' על ניירות ערך זרימת שינויים בדרישות מתקבלות בברכה, אפילו מאוחר ספק לעיתים קרובות תוצרים פועלים העדפת תוצרים פועלים על תיעוד -- -- מודעות ליעדים עסקיים חיזוק הצוות תיכון עמיד )"ירוק"( איכות מצוינות טכנולוגית שיפור מתמיד דחיית החלטות צוות עצמאי, מוטיבציוני ובעל סמכויות נרחבות -- נושא חשוב ביותר חתירה למצוינות טיפוח סביבה לומדת דחיית החלטות ומחויבויות לרגע האחרון האפשרי מובנה אנשי העסקים לעבוד יום יומית יחד עם המפתחים בחירת אנשים בעלי מוטיבציה, ארגון עצמי של הצוות, Scrum התהליך מעודד פיתוח "ירוק"-משפר איכות תיכון מבוסס בדיקות, מוכן לייצור תשומת לב למצוינות טכנולוגית ותיכון טוב הצוות בודק את עצמו בתכיפות ופועל לשפר את התנהלותו בהתאם -- -- הנדסה משולבת

האם הפתרון הוא תהליך?Lean - Agile כל העובדות הללו מובילות אותנו לנסות תהליך פיתוח פרקטי המערב Lean-וAgile אבל נדרשים כמה שינויים: במקום הגדרת "תוכנה מוכחת" כפי שמופיעה ב- Manifesto Agile נגדיר תכן שהסיכוי לבצע בו עבודה חוזרת הוא מינימאלי. הגדרה כזו מאפשרת לנו להכיל גם תוצרי "נייר" שמתקבלים בשלבים המוקדמים של תהליך הפיתוח. הגדרה כזו מחייבת הוכחה טובה של כל תוצרי ה"נייר", לפני שחרורם )כמו סימולציה או דגמים מוקדמים( הזמן האופייני של "Sprint" יוארך ל- 6-8 שבועות תהליך הפיתוח הרזה הינו תהליך מתמשך ולא אוסף של אירועים כמו תהליכי.KaiZen אנו משתשים בהגדרות הבזבוזים שניתנו ע"י פרופ' בו אופנהיים הנדסת 102

יתרונות וחסרונות של Lean-Agile ייתרונות תהליך פיתוח מהיר וקבלת תוצר מהיר במחזור חיי הפיתוח הכולל פיתוח בשלבים: מהלך של פיתוח מודולים והוספת הדרגתית של יכולות, לכן פחות רגיש לשינויים תהליך מבוסס בדיקות מבטיח איכות גבוהה ופחות גישות לתכנון שהסתיים התבססות על ידע מדוד שנצבר בפרויקט, מצמצם את השפעת פרדוקס הידע בעיות מתגלות מוקדם וקל, יחסית, לבדוק את התוצר, לתקנו ולעקוב אחר סיכונים הנותרים במהלך כל איטרציה רלוונטית יחסית, כל איטרציה קלה לניהול ולהשגת לו"ז הפיתוח חסרונות: נדרשת מיומנות בניהול איטרציות. הצלחת הפרויקט תלויה באיכות ניהול הסיכונים והאיטרציות. הארכיטקטורה המערכתית עלולה להיות בעייתית שכן לא כל הדרישות נאספות בהתחלה וכן נטייה לאופטימיזציה מקומית קושי בניהול הדרישות המערכתיות, עקב הטיפול הנפרד בכל "ספרינט" יותר עבודה בניהול הדרישות, הממשקים, תכנון הבדיקות וניהול תצורת המערכת הנדסת 103

הנדסת 1.2.4.2.3 עבודה עם Lean-Agile בפרוייקטים מהירים עם סיכונים רבים בסביבה עתירת שינויים 104

105 כמה עקרונות קשר קבוע עם כל בעלי העניין הרלוונטיים. תאום צפיות מתמיד, שותפות ב- Trade-offs והתאמת רציפה של תוצאות התיכון לציפיות בעלי העניין. שימוש בדגמים מוקדמים. הנדסת מוריד את סיכוני הפיתוח וגורם לשיפור הבשלות, גם אם לא קיימים כל הדרישות והמידע הנחוצים. לא להמתין להשלמת הדרישות, אם אינן קריטיות לתיכון הדגמים עבודה איטרטיבית. ביצוע חבילות עבודה קטנות ובלתי תלויות ואספקתן בפרקי זמן קצרים וקצב קבוע. איטראציות קצרות של מרכיבים, באיכות גבוהה )מאפשרת מוכנות לייצור שלהם(, מוסיפה, באופן שוטף, ערך ללקוח. תהליך כזה מאפשר גם לימוד מתמיד ובעזרת תיעדוף נכון, גם הורדה מוקדמת של הסיכונים העיקריים שזוהו בפרוייקט הסקת מסקנות המבוססות על תוצאות תוצרי הפיתוח במקום על אנליזות ותחזיות. תיכון מובנה בדיקות. זהו חלק אינטגראלי של התהליך האיטרטיבי של הפיתוח שמאפשר קבלת תוצרים "פועלים" מוכחים, באופן שהסיכוי שתידרש עבודה חוזרת, קטן למינימום דחיית מחויבויות והחלטות עד לרגע האחרון האפשרי. לאופטימיזציה משופרת של תוצרי התיכון והתבססות על מדידות עובדות במקום חיזויים שימוש מסיבי ברכיבי מדף, Reuse מהירים ומוכחים העצמת הצוות. מערכיות ביטול מכוון של בזבוזים בתהליך ותיכון קומונאלי. עצמאות מירבית, בקרה חיצונית מינימאלית, קבלת הפתרונות לימוד עצמי ויכולות

סיפוק צרכי בעלי העניין בהנדסת מערכת מסורתית, הקשר של מהנדס המערכת עם בעלי העניין מסתיימים לעיתים במסמכי דרישות, מפרטים, ממשקים, תהליכי בדיקה ותו לא. לעיתים קרובות מתנתק מהנדס המערכת בכוונה מבעלי העניין על מנת למנוע שינויי דרישות הנובעים ממעורבות יתר השיטה האגילית מחזקת את הקשר עם בעלי העניין, מעורבות רציפה בכל השלבים, תאום צפיות מתמיד, שותפות ב- Trade-offs והתאמת רציפה של תוצאות התיכון לציפיות בעלי העניין. ה הללו מתאימות יותר לצרכי בעלי העניין. לעיתים מתקבל גם חסכון בזמן Rework ע"י מניעת אי הבנות הנדסת 106

עבודה איטרטיבית - למידה מתמדת פיתוח ובדיקת חבילות קטנות המסוגלות לתפקד בצורה עצמאית תוך הקפדה על ראייה רחבה ובחינת חלופות. חבילות אלו אינן סופיות ויכולות להשתנות במהלך הפיתוח. לכן, חבילות אלו צריכות להיות פשוטות ובנות עדכון לאורך הדרך האיטרציות צריכות להתרחש במרווחים קבועים שמירה על מירב האפשרויות פתוחות בכל איטרציה שיפור איכות ע"י פיתוח "בדוק" של כל איטרציה והבאתו למצב של מוכנות לייצור )בקרת איכות המוצר במהלך המחזור עצמו( לימוד מתמיד = תגובה לשינויים )מינימיזציה של נזקי השינויים( תיעדוף מפורט של המשימות מדידת התקדמות מבוססת על "תוצרים" תוספת ערך מתמשכת ללקוח והכוונת המשך הפיתוח על סמך מסקנות מאיטרציות שהסתיימו התמקדות בפתרון בעיות נקודתיות מזרז ומיעל את הפיתוח מטרות קרובות שומרות על קצב עבודה מהיר הנדסת 107

איכות תיכון מונחה בדיקות בזרימה מהירה, אין מקום לעבודה באיכות ירודה: מסמכי הבדיקות והאינטגרציה לאימות הדרישות המבצעיות של בעלי העניין הם חלק מהפיתוח עצמו הבדיקות משולבות בפיתוח בדיוק כמו רכיבי המערכת עצמם. הן חלק מאספקת המוצר ללקוח ולמשתמש המבצעי אין אירועים המתוכננים לביצוע לאחר הפיתוח גישה זו מבטיחה את האחריות והמחויבות האישית של כל אחד מחברי צוות הפרויקט לתוצאה הסופית ולא לאבן דרך פנימית כלשהי. חשיבה רזה מניחה שכל בני האדם עלולים לטעות,ולכן יש צורך בתהליך mistake-proof עם מנגנוני הגנה שלא יאפשרו טעויות איסוף הדרישות וניהולן מהווים בסיס למוצר איכותי. כל מערכת יכולה להשתנות בעתיד, לכן יש צורך במפרט בדיקות וטכניקה המשלבת אינטגרציה ובדיקות בתהליך הפיתוח, שיוודא שגם לאחר ביצוע שינויים, שאר המערכת לא נפגע אוטומציה של הבדיקות היא השקעה טובה בעידן של משאבים מוגבלים, ומאפשרת תכן מבוסס בדיקות הנדסת 108

109 התחלה מוקדמת העדפת ניסויים על ניתוחים התחלת פעילות פיתוח כאשר קיים מספיק מידע, ללא המתנה לאיסוף כל הדרישות. יש לאסוף את כלל המעורבים בפרויקט יחד על מנת להתוות את הפרטים ולהתניע את הפעילות איסוף מוקדם של כלל דרישות בעלי העניין עלול להיות בעייתי עקב מורכבות ה המפותחות, טכנולוגיות שאינן מוכרות לבעלי העניין או חוסר ייציבות הטכנולוגיות. לעומת זאת, פיתוח משולב עם הגדרת דרישות משפר את חשיפת הנדסת בעלי העניין, בשלבים מוקדמים, לטכנולוגיות ושל המפתחים ל. כך מתקבל אפיון טוב יותר ומרכיבי מערכת בשלים יותר תחילת הפיתוח במקביל להעלאת צורך עלולה להיות בזבזנית ולגרום לאילוצי לתכן ולפתרון לא מיטביים. מנגד, היא מייצרת תועלות בהבנת ה לעומקם והבנת גבולות ישימות מערכת יש להבטיח שימוש באבני בניין קיימות, מודולאריות, ותקינה אחידה התיכון המערכתי והקונספטואלי צריך לסמוך על מרב המידע שקיים בעת התיכון שלהם. יש לתכנן מוקדם את תהליך האינטגרציה ולשלב את ההכנות לתהליך בפיתוח השוטף. תהליך האינטגרציה צריך להתחיל ברגע שיש חומרה או תוכנה פועלים קיימת נטייה לפצל בעיות לבעיות משנה בלתי תלויות, כך שבחינת התכן השלם במרחב ה נעשה מאוחר, לאחר פתרון בעיות המשנה. שימוש באבי טיפוס והפיתוח המקדים בכללותו מבטיחים את בחינת ה המרכזית לכל אורך הדרך.

דחיית מחויבויות והחלטות הנדסת מושג יסודי בתפיסת הפיתוח הרזה שמשמעותו שמירה על מרחב החלטות מירבי ומירב אפשרויות פתוחות כל עוד הדבר אפשרי. ההחלטות צריכה להתבצע ברגע האחרון האפשרי, כלומר הרגע שבו אי קבלת ההחלטה עלולה לבטל אלטרנטיבה חשובה פירוק התכולה לגורמים יסודיים פשוטים ככל האפשר ומניעת צימודים )צמצום הקשר ביניהם(. חיוני גם לפשטות האינטגרציה והתחזוקה ושימור יכולת השינוי העתידי במערכת עיכוב החלטות בלתי הפיכות מאפשר התבססות על ידע שהצטבר מאירועים ידועים, ולא על תחזיות. כאשר החלטות נעשות לפני שכל העובדות ידועות, יש להקטין את תלות ההחלטה בתחזיות. דחיית המחויבויות מצמצמת את השפעת השינויים עקב אי התייחסות לדרישות שטרם התקבלו לגביהן החלטות נדרשת יכולת תגובה ארגונית מהירה להחלטות. יש לבחון כיצד לקלוט ולהטמיע שינויים הן טכנולוגיים והן הארגוניים. בין הטכניקות המומלצות ליישום בהקשר זה ארכיטקטורה מבוססת על "הפרדה לשכבות" הימנעות מחזרה על פיתוח רכיבים יצירת אזורי גמישות מוכוונים הימנעות מרכיבים שאינם חיוניים 110

אופטימיזציה גלובלית הנדסת ב- WBS הפרויקט מפורק לחבילות עבודה שמתנהלות בנפרד. פירוק מורכבות לחלקים קטנים, מקלה את הניהול אך עלולה לגרום לאופטימיזציות מקומיות. ניהול כזה מתעלם מזרימת שרשרת הערך. הוא עוסק בעלויות ובזמן הדרושים למשימות, אבל לא לוקח בחשבון את הערך של זמני האינטראקציה ושל הדברים שלא נעשים. הצורה הנכונה למדידת התקדמות פרויקט היא זו שמשקפת את הערך העסקי שהושג בפרויקט. ככלל, על מנת לשפר שיתוף פעולה, יעיל יותר למדוד ביצועים של צוות, ולא ביצועים של בודדים. 111

הורדת סיכונים מוקדמת הנדסת Source: Chris Shayan- Agile Software Development Methology, Feb. 2010 112

העצמת הצוות בזרימה מהירה של עבודה ותגובה מהירה, אין זמן לבקרה מרכזית מעמיקה. סביבת העבודה צריכה להתאים לעבודת עצמאית של הצוות בתהליכי פיתוח מסורתיים מדגישים את תהליכי הדוקומנטציה המתאימים יותר לייצור מאשר לפיתוח מתאים יותר להדגיש את התוצרים הפועלים. לדוגמא: במקום לגייס מהנדסי תעשייה לתכנון תהליכי הייצור, בטויוטה לימדו את העובדים לבצע פעילויות של מהנדסי תעשייה לעיצוב שיטות עבודות משלהם באמצעות תוכניות הכשרה אגרסיביות יצירת סביבת פיתוח מתאימה, כרוכה בשחרור המגבלות מהאנשים העובדים ושיתוף במטרת הפעילות, במקום מתן הנחיות ספציפיות משעה שהצוות מבין מה המטרה, הם יידעו האם התהליכים הקיימים דורשים שיפור כל פרויקט פיתוח צריך להתחיל בבחירת צוות מתאים להשגת ה. כל סבב פיתוח צריך להתחיל בסיקור התהליכים ועדכונם. חשוב להקצות את הזמן לבניית התהליך הנכון צריך להבטיח תקשורת תוך צוותית מושלמת להקנות לצוות הרשאה לפתור את Stoppers" "Show כל אלו ישפרו את המוטיבציה ויביאו לשיפור איכות הצוות הנדסת 113

Scrum הנדסת Scrum הוא מערך שחקנים דחוס במשחק הרוגבי. הרעיון הוא של הצטופפות השחקנים עם חידוש משחק לאחר עבירה, במטרה להעביר את הכדור לכיוון שער היריב מסגרת של ניהול פרוייקט לביצוע זריז של פרוייקטים. המטרה העיקרית היא לספק תוצרים, שלאחר כל איטראציה מספקים את הערך העסקי הגבוה ביותר. מבוסס על מחזורים בני כ- 30 יום המכונים "Sprints" העיקרון הבסיסי ב- Scrum הוא שהצוות מארגן את עצמו ( self.)organizing המשמעות היא שהצוות אינו עוקב אחרי תוכנית קבועה או סט של משימות, אלא מארגן עצמו להיענות ליעדי ה- SPRINT, ובהתאם קובע את פעילויותיו בפגישות ה- Scrum היומיות גודל הצוות המומלץ הוא 4 עד 9 חברים http://www.devx.com/architect/article/32761/ 114

הנדסת Scrum קורס הנדסת Source: Mike Cohn - Succeeding with Agile: Software Development Using Scrum, 2009 115

Scrum.1.2.3 הנדסת כל יום )או בתדירות גבוהה אחרת(, באותה שעה, צוות הפרויקט נפגש לשיחה. מצפים שהחברים יעמדו במהלך כל הפגישה ע"מ לעודד פגישות קצרות, רצוי של לא יותר מ- 10 עד 15 דקות. כל חבר, בתורו, עונה על 3 שאלות: מה עשיתי מאז פגישת ה- Scrum האחרונה? מה התוכניות שלי מעתה ועד לפגישת ה- Scrum הבאה האם יש לי מחסומים כלשהם שמפריעים להתקדמותי זוהי אינה פגישת סטאטוס. אין כאן דיווח על אחוז גמר. מדובר רק בעבודה שנעשתה, מה הושלם ומה לא. כאשר מזוהה מעצור בהתקדמות, הוא מוגדר כמחסום. כאשר מדווח על מחסום, הקבוצה מחליטה איך לטפל בו, כולל דיווח מיידי בערוצים הדרושים בחברה. כאשר מספר צוותים מעורבים בפרויקט, היררכיה של פגישות Scrum יומיות יכולה להיווצר Scrums.Scrum of לדוגמה, שלושה צוותים מעורבים בשלושה SPRINTS שונים אך קשורים. כל צוות מקיים את המפגש היומי ובהמשך, חבר אחד מכל צוות נפגש לפגישת Scrum נוספת שמיועדת לתאום הצוותים. המידע מהמפגש הזה מפוזר למחרת במפגשי ה- Scrum של כל הצוותים. 116

Scrum בסוף ה- Sprint, הצוות, יחד עם בעלי העניין הרלוונטיים, נפגש ע"מ להציג את העבודה שבוצעה ולגבש את עדיפויות ה- Sprint הבא. בנוסף, נדונים גם כל המכשול החשובים, בהם נתקל הצוות, ההשפעה שלהם ודרכי פתרונם. יש לציין שה- Scrum מתמקד באספקטים הניהוליים של הפרויקט ולא מפרט גישות טכניות. לכן, ניתן לשלב גישות Agile אחרות, כגון XP הנדסת כמה עקרונות נוספים תמיד צריך להיות )גם תיאורטית( מוצר שאפשר לספק יש לבנות דגמים מוקדם ולעיתים קרובות יש לבצע בדיקות בעקביות ובאופן מתמשך יש להניח שהדרישות יכולות להשתנות ולשמור על יכולת להכניס שינויים במהלך הפיתוח יש לעבוד בצוותים קטנים- במקביל תוך ריבוי תקשורת וצמצום התקורה על פי הרצאה על ה- http://www.controlchaos.com/scrumwp.htm SCRUM Model 117

אז... איך זה עובד? שימוש בתהליך "Scrum" של,Agile אך הורדה של מרבית הבירוקרטיה ומתן אפשרות למוצר "לדבר". ביצוע סקרי עמיתים קטנים ומרובים )בשתוף בעלי העניין הרלוונטיים( להבטחת איכות הפיתוח ויעילותו בשלבים מוקדמים יוצרים רשימה של חבילות עבודה, מתעדפים אותה ומצוותים את קבותות העבודה )ראה דוגמה( הנדסת 118

119 איסוף שם חבילת העבודה דרישות בעלי העניין והכנת סקר בדיקת חלופות לקונספט מערכתי ובחירת הטוב ביותר הכנת מפרט תיכון תיכון הגדרות "על" לפיתוח מערכת "על" מערכתי מפורט של המוצר "על" ראשוני של המוצר "על" של מפרטי וממשקי מכללים תכנון משימות הפרוייקט דוגמת חבילות עבודת הפיתוח ותיעדופם הכנת מפרט מע' מפורט של מכלול התקשורת תיכון דגם ראשוני של מכלול התקשורת בניית דגם ראשוני של מכלול התקשורת ובדיקתו תיכון מעגל בקרת התקשורת, כולל סימולציה בניית מעגל בקרת התקשורת ובדיקתו הנדסת מע' IPT הנדסת מע'+אופטיקה;אלקט';מכ' הנדסת מע'+אופטיקה;אלקט';מכ'; ILS הנדסת מע'+אופטיקה; אלקט'; מכ' הנדסת מע'+אופטיקה; אלקט'; מכ'; זיווד; ILS הנדסת מע'+אופטיקה; הנדסת מע' הנדסת מע' אלקט'; מכ' )+אנשי תקשורת( הנדסת מע'+אלקט';מכ';הרכבות; הנדסת מע'+אלקט'; מכ';ייצור מעגלים;הרכבות הנדסת מע'+אלקט';מכ'; ILS ;ייצור מעגלים;זיווד;הרכבות זיווד הנדסת מע'+אלקט';מכ';ייצור מעגלים; הרכבות הנדסת משך הביצוע 3 שבועות 3 שבועות 3 שבועות 3 שבועות 3 שבועות 3 שבועות 1 שבוע 1 שבוע 3 שבועות 6 שבועות 3 שבועות 6 שבועות 38 שבועות

דוגמה למבנה צוות משימתי תכולת עבודה: תיכון דגם ראשוני של מכלול התקשורת משך פעילות: 3 שבועות תדירות מפגשים: פעמים בשבוע מהנדס מע' ר"צ אלקט' ר"צ מכניקה הרכבות בקרת תצורה רכש בדיקות הנדסת בדיקות ר"צ-זיווד זיווד אנליזות תרמיות תאימות אלמ"ג מכשירנות בדיקות ר"צ-מכניקה מכניקה ר"צ זיווד אנליזות חוזק מכשירנות בדיקות ר"צ-אלקטרוניקה תקשורת Embedded HW Embedded SW Signal Integrity הרכבות אלקט' סימולציות 120

דוגמה לניהול פיתוח מערכת מורכבת IPT -ים שבועיים ממוקדים לפי הנושאים והדיסציפלינות הבאות: כללי-ניהול התוכנית הנדסת מערכת בטיחות מערכת ותוכנה, ARM אלקטרוניקה-תאלמ"ג-רתמות-ספקים מכניקה-אופטיקה-אנליזות-זיווד -חומרים עיבוד תמונה-בקרה-תוכנה מחוש תרמי לייזר תכנון מערכי אינטגרציה צב"דים תנאי סביבה וניסויים בדיקות תוכנה + סימולטורים הנדסת סיכום מסודר של כל IPT ניהול טבלת Action Items פרוייקטאלית 121

לסיכום ה- Lean-Agile הנדסת חוסר הוודאות מובנה בפרויקטי פיתוח, לכן יש לאמץ אסטרטגיות להתמודדות יעילה עם כך. העמדת פנים שהיא לא קיימת היא דרך לא יעילה להתמודדות, גישה שרווחת כיום בניהול פרויקטי פיתוח רבים אסטרטגיה של פיתוח ובחינת מרכיבים בתהליך איטרטיבי, )והימנעות מפיתוח העשויות כמקשה אחת( היא דרך יעילה להתמודדות עם חוסר הוודאות. פיתוח מצטבר שכזה, המשולב עם שחרור דרישות בשלבים, מאפשר לחלק פרויקטים לחבילות קטנות שניתן לנטר בנפרד תפיסת הפיתוח Lean-Agile מעודדת התחלה עבודה מוקדמת עם מערך של אפשרויות שנשמרות פתוחות כל עוד ניתן תפיסת הפיתוח Lean-Agile מעודדת בניית מערכת ארגונית ואנושית המאפשרת הסתגלות והתאמה מהירה ל המשתנים, תוך אספקה ומענה מהיר ומיידי פוטנציאל התועלת בהיבטי משאבים ולו ז, לכל הפחות דומה להיקפי הצלחה של מתודת ה- Lean-Agile בתהליכי הייצור/התוכנה ומגלמת בתוכה פוטנציאל התייעלות וחסכון גדולים Optimizing Lean Product Development for Aerospace and Defense Manufacturers, Aberdeen Group, 2009. Lean Development & the Predictability Paradox, Mary Poppendieck, 2003. עקרונות למחקר ופיתוח בעידן הנוכחי, יריב חסר, 2007 122

רידוד דרישות דרישות הנדסת לאתגר כל דרישה לקבל חשובות מאד עלות מימוש יקרה לשאוף לבטל לשקול לבטל זולה לא חשובות 123

גיבוש וסינכרון תהליך פיתוח איך עושים זאת? הנדסת ביחד ע"פ איציק בן לוי 124

תוצרי תהליך רידוד הדרישות קיצור Time to Market ובמיוחד בשלב הפיתוח הבנת תיעדוף הדרישות משמעותו הכלכלית - בחירת פיתרון מועדף לבעלי העניין )גם באספקט הכלכלי( קיצור זמן משמעותי בכתיבת הדרישות ופיתוח הדרישות מניעת סבבי פיתוח מיותרים זיהוי מוקדם של הסיכונים הורדת עלויות פיתוח הנדסת 125

בחירת מודל מחזור חיי הפיתוח עקרון ה"קשקוש": תכנן לזרוק את הגרסה הראשונה. בכל מקרה תעשה זאת. Fred Brooks, The Mythical Man-Month: Essays on Software Engineering, Addison Wesley, 1975. Revised in 1995 לכל פרוייקט קשיים וסיכונים משלו, לכן כמעט ולא משתמשים במודלי מחזור חיי הפיתוח כפי שהם מודל "מפל המים" הינו מודל גנרי שמשמש תמיד בוריאציה זו או אחרת דגמים מוקדמים יכולים לתת לבעלי העניין ולמפתח תחושה חזקה לגבי יכולות המוצר המפותח ובעיותיו. השימוש בהם, בעיקר במודלים האבולוציוניים, נמצא בשימוש הולך וגובר, תוך שימת דגש על דגמים ראשונים מהירים טעות בבחירת מודל מחזור חיי הפיתוח הינה יקרה, הן במובן הכלכלי והן במובן היכולת לעמוד ביעדים התפקודיים במועדים שתוכננו ישנה נטיה להפחית במספר הדגמים המפותחים, במיוחד אם אין דרישת בעלי העניין. יש לבחון סוגיה זו באספקט של בשלות המוצר והיכולת לייצר מוצר הדיר בעלויות סבירות. הנדסת 126

הנדסת 1.3 ניהול דרישות If you don't know where you are going, you will wind up somewhere else. Yogi Berra 127

הנדסת 1.3.1 מבוא 128

הבנת גבולות המערכת המערכת מתוארת בהתחלה כ"קופסה שחורה" הקופסאות השחורות "מולבנות" ומציגות את תתי ה וכן הלאה... הקווים שחוצים את גבולות המערכת הינם הממשקים הנדסת רכיב תת מערכת מערכת 129

הבנת גבולות המערכת במערכת של הנדסת גבולות המערכת ממשקים תת-מערכת פוד צילום תת-מערכת תחנה קרקעית חשמל איזור פעולה הפעלה BIT ממשק מצלמה אויר- Aero-optics 130

אימות ותיקוף בדיקות פורמאליות הערכות לייצור שילובים ובדיקות תהליך הפיתוח המערכתי תיכון ראשוני מפרטי מערכת תכן המערכת הגדרת דרישות וממשקים איסוף זיהוי בעלי העניין הנדסת ייזום הפרוייקט PRS SRD PDR שילובים ובדיקות PDR הוכחת הקונספט תיכון ומימוש מערכתי תיכון ומימוש מרכיבי המערכת SSRD תכן קונספטואלי / CDR αrr אימות ותיקוף תיכון מפורט הגדרת מפרטים וממשקים דיסציפלינארי איסוף ייצור הרכבה ובדיקות תיכון ומימוש מכללים / SSRD PDR CDR מימוש תכן תכן ועריכה מפורט על כרטיסים השלמת מפרטים וממשקים FAI PCA FCA ייצור סדרה ראשונה 131

הנדסת 1.3.2 איסוף צרכי בעלי העניין 132

מהו פרויקט? פרויקט הוא מאמץ זמני שמושקע ביצירת מוצר, שרות או תוצאה ייחודיים זמני: עם התחלה מוגדרת וסיום מוגדר. סוף הפרויקט מוגדר כאשר הפרויקט השיג את יעדיו או שברור שאי אפשר או לא מעוניינים להשיגם מוצר, שרות או תוצאה ייחודיים: יצירת משהו )פריט סופי או רכיב של פריט( שלא נעשה קודם בדרך זהה, לכן הוא ייחודי או נבדל יכולת לבצע שירות כמו תפקודים עסקיים שתומכים בייצור או בהפצה תוצאה, כמו ידע חדש. למשל מו"פ שמפתח ידע לבדיקת קיום מגמה או תהליך חדש בעל ערך לחברה מתבצע באופן הדרגתי: מתקדם בצעדים ונמשך תוך התקדמות מתמשכת בדומה לתפעול, פרויקט... נעשה ע"י אנשים עם משאבים מוגדרים בצורה מתוכננת ומבוקרת הנדסת ע"פ ה- 2008 PMBOK 133

לקוחות ובעלי עניין "לקוח" )Customer( כל אדם או גוף שיכול לחייב הגדרת דרישות למערכת. "בעל עניין" )Stakeholder( א דם או גוף שיכול להשפיע על או להיות מושפע מתוצר המערכת או הצלחת הפרויקט לכל אחד מבעלי העניין נקודת מבט משלו הנדסת 134

א-פרופו נקודת מבט שיכור שהדיף ריח נורא של אלכוהול זול, עלה לאוטובוס והתיישב עם תרמילו המלוכלך ליד כומר בעל מראה מכובד. מן התרמיל הוא שלף פיסת עיתון ישנה ובקבוק קטן של ג'ין ולגם ממנו בשלוק את כל מה שנשאר בו. הכומר התעלם מהשיכור והכריח את עצמו להסיט מבט ולהתרכז בנוף. כעבור מספר דקות פנה השיכור אל הכומר ושאל: "סלח לי אדוני, אולי אתה מכיר את הסיבות לדלקת פרקים?" הנדסת הכומר, באי נוחות מתגברת, ענה לו בטון מתנשא וציני: "בוודאי שאני מכיר. חיים לא מסודרים, חברתם של נשים לא מוסריות, שימוש מוגזם בטבק ובאלכוהול, הוללות בבתי זונות ועוד הרבה גועל נפש מסוג זה!" "וואו!!" ענה השיכור וחזר לקרוא את העיתון. הכומר הטוב חשב שנית על תשובתו והרגיש צורך להתנצל בפני השיכור "סליחה", אמר לו בטון מפייס "לא רציתי להעליב אותך. כמה זמן אתה כבר סובל מדלקת פרקים?" "אני?" הופתע השיכור "אף פעם לא סבלתי מזה, אבי. רק קראתי בעיתון הזה כי האפיפיור סובל מדלקת פרקים כבר שנים!" 135

מיהו הלקוח? בחברות שמפתחות פתרונות,Turn-Key הלקוח הוא זה שמגדיר את צרכיו, בצורה מפורטת, המגדירה את כל מה שהוא חושב שצריך להגדיר. היצרן כמומחה, חייב לוודא סבירות ולהשלים את הדרישות על מנת לקבל הגדרה מלאה ושלמה של דרישות בעלי העניין לעיתים, כאשר הלקוח אינו סבור שיש לו דעה מספיקה לגבי תוצאות הפיתוח, הוא יבקש את סיוע המפתח, או גוף שלישי על מנת להגדיר את דרישותיו. במקרה כזה, יש לתאם ציפיות באופן הרבה יותר יסודי מאשר במקרה הקודם כאשר מפתחים מוצר שמיועד לשוק, ללא לקוח מזוהה, ממנה הארגון נציג לקוח, בדרך כלל איש שיווק, המכונה לעיתים קרובות מנהל המוצר Manager(,)Product שמייצג את הלקוח במפעל. לרשותו של מנהל המוצר עומדים כלים רבים, כגון מידע על מצב השוק וצרכיו, פעילות מתחרים, מגמות של פיתוח מוצרים חדשים וכן מידע שיכול להתקבל מסקרי שוק או משיתופי פעולה עם חברות אחרות שמשלימות את יכולת המפתח, למשל חברות שיווקיות אם המוצר אינו מוכר כלל למשתמשים, אין טעם לסמוך בלעדית על סקרי שוק ויש לתת משקל חזק ל- Vision של הייזם, תוך כדי בקרתו ע"י חשיפה מבוקרת של המוצר ללקוחות שמוכנים להשתתף בתהליך כזה )קבוצת מיקוד( הנדסת 136

דוגמה של חברת רכש לא גדולה מיהו הלקוח? הנדסת 137

אנשים או ארגונים שיש להם עניין במערכת או שהם מושפעים ממנה הן ישירות והן בעקיפין מיהו בעל העניין? הנדסת למי כדאי להקשיב בעת הגדרת המוצר החדש? מהם מגזרי בעלי העניין? מהי שרשרת הערך בכל מגזר? האם יש להעדיף קולו של בעל עניין אחד על פני אחר? האם להתייחס לבעלי עניין כמו ללקוחות? המוכר המשווק קובעי תקן המחוקקים המשנע יצרן הצב"ד הבעלים היצרן המרכיב מי משלם? מי מגדיר? מי מאשר? מי משתמש? מי יוצר קשר? יש להתייחס ל, העדפות והציפיות של כל בעלי העניין הרשויות המתנגדים הדורש המשלם הרוכש על פי ד"ר עמי הרי המחסנאי המדריך המתחזק המשתמש 138

אנשים או ארגונים שיש להם עניין במערכת או שהם מושפעים ממנה הן ישירות והן בעקיפין המוביל מיהו בעל העניין? המדריך המתחזק הנדסת למי כדאי להקשיב בעת הגדרת המוצר החדש? מהם מגזרי בעלי העניין? מהי שרשרת הערך בכל מגזר? האם יש להעדיף קולו של בעל עניין אחד על פני אחר? האם להתייחס לבעלי עניין כמו ללקוחות? מע' אחרות קובעי התקן המוכר המשווק יצרן הצב"ד הבעלים המחסנאי הצבע על פי ד"ר עמי הרי המרכיב מי משלם? מי מגדיר? מי מאשר? מי משתמש? מי יוצר קשר? יש להתייחס ל, העדפות והציפיות של כל בעלי העניין היצרן המפתח המשתמש המחוקקים הדורש הרשויות המתנגדים המשלם הרוכש 139

מה כל בעל עניין רוצה? הנדסת 140

מה קורה כאן? הנדסת 141

מהגדרת ה לתאור ה מצב בעיתי הפער בין המצוי לרצוי )תיאור מצב( פתרון - ביטול מצב בעיתי ע"י ביטול הפער בין המצוי לרצוי הנדסת 4.3 ניהול פרויקטים מאת שלמה גלוברזון, אבי שטוב ועופר צביקאל אפיון צורכי לקוח 142

מה הוא צורך הנדסת צורך הוא דבר מה הדרוש לאדם או שהאדם רוצה בו ישנם קולקטיביים, לדוגמא צרכי קהילה )למשל איכות הסביבה( מוצר שמוכנים לשלם עבורו, עונה תמיד לצורך בכדי לתת מענה אמיתי ל נדרש לזהות את המשימות האמיתיות אם בעל עניין מנסח צורך במונחים של פתרון, נדרש להגיע אל הצורך האמיתי ע"י השאלות: למה צריך את הצורך? מה מטרת הצורך? מקור: דרורה גושן-קורס הנדסת לחברות קטנות ובינוניות. מרץ 2012 143

ביטוי הצורך משפט המבטא יתרון ללקוח שיפור מצב עוסק בבעלי העניין ובמצביהם ולא במוצר אינו תלוי בטכנולוגיה של המוצר מגדיר ערך ללקוח. עוסק בפתרון ללקוח )לא הפתרון הטכני עצמו( יש עסקיים כמו הגדלת הכנסות, צמצום עלויות, שיפור שירות, מענה לתקנות צרכי בעלי העניין ניתנים לתיעדוף הנדסת מקור: דרורה גושן-קורס הנדסת לחברות קטנות ובינוניות. מרץ 2012 144

תהליך זיהוי צרכי בעלי העניין בניית פורטפוליו - זיהוי משפחת המוצר ניתוח יעדי שוק, מגמות ותחרות הצגת מגזרי הלקוחות. הצגת צרכי בעלי העניין העיקריים בניית וניתוח תרחישי ע"י בעלי העניין. הצגת הערות Like, Dislike תיעדוף ה הצגת מתחרים כולל Best in Class איתור והגדרת Key Buying Factors רישום ה הגדרת התועלות והעדפות בעלי העניין של בעלי העניין הנדסת ע. הרי רח כספרי 25 חיפה, 34677 145

תהליך זיהוי צרכי בעלי העניין )המשך( הגדרת מפורשים מה המוצר צריך לעשות לימוד ה הבסיסיים מה הלקוחות מתארים לעצמם שהמוצר יעשה חשיבה על מלהיבים שיגרמו ללקוחות להיות מאד מרוצים זיהוי שהלקוח לא מודע להם עצם תהליך של איסוף ועיבוד )מיצוי( ה מאפשר זיהוי של נוספים של בעלי עניין, איתור ולימוד מתחרים, פיתוח סימולציות וכו' הנדסת כמה יש לאסוף: מעט מידי יש סיכון בהגדרה לא נכונה של המוצר הרבה מידי סיכון של בזבוז זמן יקר ללימוד בעיות פחות חשובות פרוט יתר יגביל את מספר הפתרונות )חשיבה יצירתית( 146

ר, קורס הנדסת.1.2.3.4.5.6.7.8 מקורות לרשימת דרישות בעלי העניין, דרישות, ויעדים חדשים או מעודכנים, במונחים של משימות,,MOEs ConOps ביצועים טכניים, סביבות משפיעות ואילוצים בסיסי נתונים טכנולוגיים, כולל זיהוי טכנולוגיות מפתח, ביצועים, בגרות, עלות, וסיכונים דרישות ממסמכים שצוטטו בחוזה, למערכת ופריטי התצורה )CIs( שלה יעדים טכניים רישומי פגישות ושיחות עם הלקוח ובעלי העניין תוצרי הניתוח התפקודי פרסומי נתוני המתחרים נסיון קודם של מהנדס המערכת הנדסת Source: INCOSE Systems Engineering Handbook v. 3.2.2, October 2011 147

שיטות לאיסוף צרכי בעלי העניין הנדסת ראיונות עם בעלי עניין סקרי שוק/שאלונים Surveys/Questionnaires( )Market קבוצות מיקוד - פגישות מובנות של בעלי עניין והיצרנים להבנת ה - Benchmarking תהליך מובנה של השוואה שיטתית בין מוצרים שירותים או תהליכים תצפיות על פעולות משתמשים ידע אירגוני או אישי סיעור מוחות חזון היזם השתתפות בכנסים וקבוצות עבודה ניתוח של מסמכים ותקנות מחייבים ניתוח סביבות התפעול בנית וניתוח תרחישים אפשריים בנית מודלים, סימולציה ואבי טיפוס לימוד מפרסומים, ומתחרים שימוש בצוותים יעודיים לאיסוף צרכי בעלי העניין 148

דוגמאות לצורכי בעלי העניין מה ה שהמערכת צריכה לתת לה מענה )צילום ויזואלי של מעי אדם ללא חדירה כירורגית( תפיסת התפעול ואימון של המערכת )המערכת תופעל על ידי טכנאים שהוכשרו לכך ע"י היצרן במשך 3 חודשים(. תפקודים מערכתיים תרחישי תפעול ראיה עתידית של התפתחות המערכת )טכנולוגית( )המערכת תוכל להיות מובלת למקומות הרצויים ללא קשר לתנועת השרירים(. תפיסת ILS והדרכת הלקוחות את המערכת )זמינות המערכת תהיה גבוהה מ- 95% מזמן ההפעלה(. הצגת ניתוח המובילים Class( Best (/המתחרים: in יש לזהות ולהגדיר את המובילים שאליהם רוצים להתייחס, המידע לקבלת נתונים וחוות דעת עליהם. ניתוח והצגת ביצועים רלוונטיים של מתחרים. כולל זיהוי מקורות הנדסת 149

דוגמאות לצרכי בעלי העניין הלקוח מעדיף שתפעול המערכת יהיה בעזרת מסך מגע עם מינימום כפתורי חומרה זמן תגובת המערכת לכל פעולת מפעיל, יהיה קצר מ- 80mSec הלקוח מעדיף ללמוד להפעיל בעצמו את המערכת ולמצות את יכולותיה המערכת תשתלב בקו המוצרים של הלקוח, בצורה שלא תדרוש כל השקעה נוספת בהתאמת קו המוצרים שלו למערכת החדשה שדרוגי תוכנה עתידיים יבוצעו מרחוק ע"י הייצרן בעזרת האינטרנט, ללא מעורבות ו/או ידיעת הלקוח הלקוח מעוניין ביכולת הרחבה עתידית של המערכת ל שהגדיר בהשקעת Life-cycle cost מינימאלית הנדסת 150

כללים להגדרת צרכי בעלי העניין הנדסת בשפת הלקוח ברורים לכל אחד בארגון. השתמש בהגדרות שכל אחד יבין הצהרות חיוביות אין בדרך כלל מספרים )הלקוחות קונים תועלות או פתרון לבעיות, פרמטרים או מאפיינים( לא ע. הרי רח כספרי 25 חיפה, 34677 151

קבוצות מיקוד הנדסת במקרים רבים תוצאות של סקר לא נותנות לנו אפשרות לקבל אמירה ברורה ואין תוצאה חד משמעית שאותה ניתן להקיש מהנתונים. במקרים אלו, לאחר המחקר הכמותי משתמשים בקבוצת מיקוד כדי להבהיר וללבן סוגיות מעורפלות. במקרה זה, קבוצת המיקוד הינה כלי מחקרי נוסף על הכלי המחקרי הקודם קבוצת המיקוד מכנסת מס' אנשים )נציגי לקוחות ובעלי עניין שונים, נציגי השיווק ומומחי הנדסה של היצרן( למספר דיונים קבוצתיים מונחים. משך כל דיון כשעתיים. בכל דיון מלבנים את נושא צרכי בעלי העניין ע"י הפריה הדדית וירידה לעומקם של פרטים דיונים כאלה יש להכין )הזמנת המשתתפים, מקום מפגש, אמצעי רישום, כיבוד קל וקפה וכו'( מהלך הדיונים )הצעה( מושב הפתיחה, בו אפשר לדון בתכולת הפרוייקט, היכרות בין המשתתפים, והגדרת בעלי העניין הרלוונטיים. מושב הדיונים, בו אפשר לדון בפרטי ה, תועלות,Like-Dislike תלונות ידועות וכד' מושב התיעדוף, בו מדרגים את ה על פי חשיבותם לבעלי העניין מושב הסיכום בו יש להתייחס למוצר כמכלול ולדון ב- Trade-offs 154

דוגמה לפעילות עם קבוצת מיקוד ביקור של מנהל בכיר וקבוצת נציגים טכניים מחברת Devices באלאופ AD נתנו הצהרה שהם רואים בנו שותף אסטרטגי הצגת ה- Road-map שלהם שאלות על מה ה שלנו ותגובות ל- Road-map דיון בפרטי ה שלנו, כולל תזמון הצורך ותיעדוף שאלות על תחושות ביקורתיות של המשתמשים פתיחת ערוצי תקשורת ופתרון סוגיות מיידיות הנדסת Analog 155

השוואת יעילות ראיונות מול קבוצת מיקוד הנדסת כאן רואים אפקטיביות של שיטות שונות לפי מחקר של Hauser, 1993 Griffin and 156

Benchmarking 157 - השוואת מתחרים - Benchmarking תהליך מובנה של השוואה שיטתית בין מוצרים שירותים או תהליכים. תהליך ה Benchmarking תחקר את בעלי העניין, לגבי כל צורך בנפרד, ובדוק מי נתפס כטוב ביותר בשוק Class( )Best in בחר מוצרים / חברות להשוואה. הגדר מדדים כמותיים להשוואה קבע את שיטת איסוף הנתונים, אסוף נתונים קבע מה הוא פער הביצועים הקיים הערך את רמות הביצוע העתידיות פרסם את ממצאי ה- Benchmarking והשג הסכמה קבע יעדים למדדים הכמותיים הכן תכנית פעולה להשגת ערכי היעד יישם את תכנית הפעולה ועקוב אחר ההתקדמות כייל מחדש את נקודות המוצא המבחנים: השגת ערכי היעד במדדים הנבחרים השגת מעמד של מוביל על פי עמי הרי רח כספרי 25 חיפה, 34677 טל: 04-8246977 פקס 8246772 04- הנדסת

הנדסת 1.3.3 תפקודיים ואיתורם 158

תפקודיים דרישות המתארות פעולות שהמערכת צריכה לבצע, ללא התחשבות באילוצים פיזיים; דרישות המתארות התנהגות "קלט / פלט" של המערכת )מתוך )IEEE-STD-830 קיימים עיקריים ומשניים עיקריים-מגדירים את ה לשמם מיועדת המערכת משניים-תפקודים נוספים שתורמים לשביעות רצון הלקוח ה יכולים להיות ניתנים למדידה )כגון מהירות, דיוק, הספק( באמצעים ממשיים )כגון כלי מדידה, ערכי נתונים, אלגוריתמים( הנדסת 159

תפקודיים ברז מים מערבב מים חמים וקרים מבקר את ספיקת המים מכוון טמפרטורת מים עוצר את זרימת המים מזגן מחמם/מקרר מודד טמפרטורת אוויר במוצא מתחבר בצורה בטיחותית לרשת חשמל ומאפשר הפעלה בטיחותית לכל משתמש או מתחזק לא מתקלקל בהפסקות חשמל מאפשר בקרת טמפרטורה/ לחות/ספיקת אוויר מאפשר כניסת אוויר טרי/סירקולציה מאפשר כיוון זרימת האוויר בשני צירים מזווד באריזה שובת עין וקלה לתליה הנדסת 160

הגדרת צורך הגדרה "מה" שהמערכת חייבת לעשות על מנת לפתור את בעיות הפרוייקט, בלי להגדיר "איך" הנתונים הנדרשים לביצוע הצורך תהליך מימוש הצורך תוצאות הצורך יש להשתמש במבטים מרובים: ניתוח תרחישי ייחוס זרימה סדרתית זרימת מידע כתיבת דרישת הצורך פעולה מתוארת ע"י פ וע ל הפועל על שם עצם, כאשר מתקיימים התנאים בהם תפקוד מתקיים הנדסת 161

איך למצוא השאלה: מהם הפעולות אשר צריכות להתבצע 1. שמעבירות כניסות ליציאות הנדסת כניסות תפקודים מערכתיים יציאות בהתחשב בכל מצבי המערכת במצב רגיל בהתחלה חמה בהתחלה קרה בכיבוי במצב בדיקה במצב מאויים במצב תקלה במצב תאונתי במצב גריטה.2 162

איך למצוא תפקודים הנדסת תפקודי בקרה כניסות תפקודי כניסה תפקודי עיבוד תפקודי יציאה יציאות תפקודים תומכים Source: Hatley &Pirbhai: Strategies for real-time syste, specifications 163

יציאות תרחיש מצולם קורס הנדסת תפקודי כניסה מאפשר ראיית התרחיש המצולם בכל עת ממקד את התרחיש המצולם על משטח סנסור רגיש לתמונה מאפשר הפעל מבזק אוטמטי/ידני חיבור ל- SDRAM ו- מיקרו SDRAM פועל עם סוללה אחת במשך לפחות 800 צילומים טוען את הסוללה מרשת החשמל ) 110-230V( מאפשר למשתמש לדעת את מצב הסוללה מאפשר טעינת הסוללה ממצב ריק למלא, תוך פחות משעה איך למצוא תפקודים של מצלמה תפקודי בקרה שולט אוטמטית/ידנית במשך זמן כניסת מידע האופטי של התרחיש לסנסור שולט אוטומטית/ידנית בכמות האור שנכנסת לסנסור מאפשר שינוי רגישות הסנסור )ASA( תפקודי עיבוד מעביר את התרחיש המצולם לסנסור תוך פחות מ- 1/10 שניה ממיר את התרחיש לאות חשמלי ברזולוציה של 6000x3000 ממיר את האות החשמלי לתקנים מוכרים,JPG( )TIFF,RAW זוכר 1000 תמונות ברזולציה מלאה מאפשר צילום מושהה תפקודים תומכים מזווד בצורה שמאפשרת פעילות בכל תנאי הסביבה האחיזה תאפשר קבלת דמות ללא תזוזת גוף המצלמה מאפשר חיבור לחצובה המשקל לא יעלה על 500 גרם, כולל עדשה וסוללה מאפשר ניידות ותליה נוחה על הכתף פועל בטמפרטורות של 10- ועד 48 מעלות, בלחות יחסית של 100% עומד בהלמים של 10Gללא פגיעה בביצועים הנדסת תפקודי יציאה הוצאת קבצי תמונות ל- PC הדפסת תמונות ישירה הפעלת מבזק אוטמטי/ידני 164

תפקודיים של מצלמה מאפשר ראיית התרחיש המצולם בכל עת ממקד את התרחיש המצולם על משטח סנסור רגיש לתמונה, ברזולוציה של 5197x3464 מאפשר שינוי רגישות הסנסור )ASA( מעביר את התרחיש המצולם לסנסור תוך פחות מ- 1/10 שניה ממיר את התרחיש לאות חשמלי ממיר את האות החשמלי לתקנים מוכרים,JPG( )TIFF,RAW זוכר לפחות 1000 תמונות ברזולציה מלאה שולט אוטומטית/ידנית במשך זמן כניסת מידע התרחיש לסנסור שולט אוטומטית/ידנית בכמות האור שנכנסת לסנסור הנדסת מזווד בצורה שמאפשרת פעילות בתנאי הסביבה מאפשר קבלת דמות ללא תזוזת גוף המצלמה מאפשר צילום מושהה מאפשר הפעל מבזק אוטמטי/ידני מאפשר חיבור לחצובה מאפשר ניידות ותליה נוחה על הכתף פועל עם סוללה במשך לפחות 800 צילומים. מאפשר הכרת מצב הסוללה מאפשר טעינת הסוללה ממצב ריק למלא, תוך פחות משעה פועל בטמפרטורות של 10 C- ועד C 48 מעלות, בלחות יחסית של 100% עומד בהלמים של 10Gללא פגיעה בביצועים 165

הנדסת 1.3.4 ניתוח ה והדרישות 166

ניתוח מבצעי וסביבתי מבוסס תרחיש/ םי יחיד לכל סוג של פעילות אלמנטים משותפים: תזמון כיסוי יכולות ביצועים ניתוח התרחישים מאפשר להבין את הצורך להפיק את התפקודים וביצועים הדרושים הנדסת 167

דרכים ליצירת תרחישי ייחוס טובים הנדסת 1. Write life histories for objects in the system. 2. List possible users, analyze their interests and objectives. 3. Consider disfavored users: how do they want to abuse your system? 4. List "system events. How does the system handle them? 5. List special events. What accommodations does the system make for these? 6. List benefits and create end-to-end tasks to check them. 7. Interview users about famous challenges and failures of the old system. 8. Work alongside users to see how they work and what they do. 9. Read about what systems like this are supposed to do. 10. Study complaints about the predecessor to this system or its competitors. 11. Create a mock business. Treat it as real and process its data. 12. Try converting real-life data from a competing or predecessor application 12 168

תרחיש טוב צריך לכלול תיאור מצב המערכת בפתיחה או בכניסה לתרחיש תיאור זרימה רגילה של אירועים בתרחיש תיאור מה יכול להשתבש ואיך צריך להגיב לשיבושים מידע על פעילויות שמתרחשות במקביל ובאותו זמן תיאור מצב המערכת בגמר התרחיש הנדסת סוגי תרחישים תרחישים תפעוליים scenarios( )Operational תרחישים תפקודיים Scenarios( )Functional תרחישי איכות Scenarios( )Quality תרחישי זרימת נתונים Scenarios( )Data Flow 169

תרחיש שימוש )Use Case( טכניקה לאיסוף וניתוח הדרישות הפונקציונליות של ושל -של-. תרחיש השימוש מורכב מרצף אירועים אחד או יותר, המתאר כיצד המערכת מתקשרת עם משתמשים )הקרויים "שחקנים"( כדי להשיג יעד עסקי או פונקציה מסוימת. השחקנים בתרחיש השימוש יכולים להיות משתמשי קצה או אחרות. בפיתוח תוכנה זריז, מקובל לכנות את רצפי האירועים בתרחיש "סיפורים". לרוב, תרחישי השימוש נכתבים בשפה פשוטה המובנת למשתמש הקצה או למומחי היישום, ולא בניב טכני. נהוג לכתוב את התרחיש כמסמך ברור וקל להבנה בעיצוב פשוט, אף שבשנים האחרונות גובר השימוש בכלים ייעודיים המסייעים בכתיבת התרחישים. הנדסת 170

תרחישי ייחוס דוגמאות לתרחישי ייחוס אחסנת המוצר שינוע )תפעולי( מערכת לא פעילה מצב של פעולה אופיינית מצב של פעולה מאומצת מצב של פעולה בתנאי קיצון מצב של פעולה במצב חירום הפסקת פעולה קצרה הפסקת פעולה ממושכת מצב של תקלה אצל המשתמש מצב של תקלה במעבדה מצב של הדרכה ואימון מצב המתנה סיום חיי המוצר וכו'... )להגדרת צרכי בעלי העניין( דוגמאות לפרמטרים של צרכי הנדסת HMI מצבי פעולה - הזנת נתונים, קליטת נתונים, הצגת נצונים מצבי תחזוקה, בדיקה ודיאגנוסטיקה - תכיפות, עומק, משך, אוטומציה, שיתוף המשתמש, שיתוף המתחזק, שיתוף המתקן איסוף והצגת היסטוריה של פעולה/תקלות מצבי תיקון 171

מס'.1 172 פרטי התרחיש פירוט ההתייחסות לתרחישי הייחוס למצלמה טריגר כניסה למצב כניסה למצב ידני. שם: צילום ידני עירור המצלמה על ידי של תמונה הנעתה שחקנים בתרחיש: משתמש ממוצע לחיצת "חצי" לחצן צילום לחיצה על לחצן מבזק זירת התרחיש: לחיצה על לחצן צילום שטח סביבת התרחיש: דרכים, יערות, בתים, הרים לחיצה על לחצן בדיקת תמונה מס' מצב 1.1 תאור המצב קביעת מסגרת הצילום מס' המצב הבא 1.2 משתמעים עדשת זום תצוגת תמונה גודל הנדסי הנדסת 14-85 מ"מ/ 1:3 מינ. צג "3 1.2 בדיקת תאורה ומיקוד 1.3 תצוגת פרמטרים 25 אותיות אלפא-נומריות בגובה 3 מ"מ לפחות 1.3 הפעלת וטעינת מבזק 1.4 מבזק ומטען No. Guide של 30 לפחות 1.4 צילום תמונה והצגתה 1.5 1.5 בדיקה נוספת של התמונה ודפדוף אחורה 3.2 צילום אוטמטי של תמונה כניסה למצב אוטומטי. עירור המצלמה על ידי הנעתה 2.1 קביעת מסגרת הצילום 2.2.3 שם: מצב Stand-By אי פעילות במשך 30 שנ' Stand-By 3.1 העברת מידע תמונה למסך יכולת הצגת תמונה על המסך יכולת דפדוף קדימה אחורה בזכרות התמונות :כיבוי המסך ומערכת הצילום הצגת תמונה למשך 2 שנ'. יכולת בחירת משך התצוגה בתפריט הראשי טיימר של 30 שניות, בר תכנות בתפריט הראשי

הכנת תרחישי ייחוס הנדסת הכנת תרחישי דוגמה תרחיש אופייני תרחיש לחוץ Activity Diagram Use Case Diagram תרחיש שכולל יבילות ותמיכה לוגיסטית מאפשר למפתחים לתרגם דרישות מצעיות לדרישות טכניות להגדיר את מעטפת הביצועים שנדרשת על פי התרחישים הללו 173

דוגמה לתרחיש ייחוס הנדסת שוטר תנועה עוצר רכב שנסע במהירות מופרזת הנהג מתנהג באופן חשוד השוטר נכנס לבסיס הנתונים תקשורת רדיו אל/מ- תחנת העבודה בבסיס תחנת העבודה בבסיס מקושרת למוקד הראשי הפעולותמוקלטות השוטר מקבל תגובת חשד השוטר לוקח טביעת בוהן השוטר מבקש בדיקה בבסיס הנתונים השוטר עוצר את הפושע הרשת מעבירה נתונים מ /אל המוקד הראשי המוקד מורה על חשד לפושע טביעת האצבעות מאשרות שהפושע מבוקש 174

ניתוח מבצעי זיהוי גבולות המערכת והסביבה זיהוי ידועות שפועלות יחד מתן תשובות לשאלות המבצעיות כמה גדול? כמה מהר? מתן תשובות לשאלות הטכניות ביצועים? מגבלות? ממשקים גבולות המערכת תת-מערכת פוד צילום תת-מערכת תחנה קרקעית הנדסת חשמל איזור פעולה הפעלה BIT ממשק מצלמה אויר- Aero-optics 175

ניתוח סביבתי הנדסת ניתוח התנאים הסביבתיים בהם המערכת נדרשת לתפקד יש להתייחס לתקנים הרלוונטיים שמכסים נושא זה )כמו,DO-160 )MIL-STD-810,ASTM D5746 לבחון את הנושאים הרלוונטיים והטווחים הדרושים מתוך אותם תקנים טמפרטורת סביבה תנאים אטמוספריים רעידות והלמים לחות נקודת טל Point( )Dew פטריות )Fongus( ברקים הקרחה, שלג, ברד חול ואבק רוחות בקרקע ובגובה אוזון קרינה סולארית ואקום חללי חגורת ואן אלן אטמוספרה קורוסיבית שדות מגנטיים כח הכובד טמפרטורה מושרית תנאים אקוסטיים עומסים סיסמיים קרינה מיננת )בחלל( קרינה לא מיננת )לייזר( 176

הנדסת 1.3.5 מבוא לניתוח תפקודי ניתוח תפקודי 177

יתרונות הביצוע של הנתוח התפקודי מפרק מורכבת לבעיות בסיסיות פשוטות מעורר חשיבה יצירתית מנחה להבנת הבעיות מוודא הגדרות נכונות לתפקודים הצגה חזותית של הקשרים התפקודיים מזהה תפקודים מיותרים מזהה תפקודים יקרים מזהה תפקודים אלטרנטיביים זולים )פונקציות( הנדסת תפקוד = פונקציה הגדרת תפקוד: ביטוי הכולל פועל + שם עצם )רצוי בר מדידה( ניתוח תפקודי 178

הנדסת Functional Analysis & Allocation Requirements Analysis קורס הנדסת Source: DSI Staff, Published 9/24/2002 Systems Engineering Analyze Preformance & Scenarios Requirement Feedbak Loop Define System States & Modes Define System Functions Define Functional Interfaces R Define Performance Requirements & Allocte to Functions Analyze Timing & Resources R Integrate Functions Analyze Failure Modes Effects & Criticality R Define Fault Detection & Recovery Behavior Internal Review Functions Refinement Loop for lower level functions FMEA Loop Design Feedbak Loop R Synthesis ניתוח תפקודי 179

פירוק פיזי לעומת תפקודי-מה צריך כדי לעוף? במשך מאות שנים, האדם לא צלח בניסוייו לעוף פירוקמאחר פיזיוניסה להשתמש בפירוק פיזי )מוח, עינים, רגלים וכנפיים( האחים רייט זיהו את התפקודים הבאים כדרושים לתעופה: המראה ונחיתה תחושת מצב ומהירות ניווט יצירת דחף אופקי יצירת כח עילוי. הנדסת ניתוח תפקודי 180

פירוק פיזי לעומת תפקודי-מה צריך כדי לעוף? הנדסת תפקוד ציפור מטוס המראה ונחיתה רגלים גלגלים, מזחלות חישת תנועה ומהירות עיניים, חוש ונטורי, מכם ראייה, מפה, INS,GPS ניווט מקום, שכל, תוואי נוף יצירת דחף אופקי יצירת עילוי אנכי כנפים כנפים מדחף או סילון כנפיים קבועות ניתוח תפקודי 181

מערכת מורכבת אופיינית הנדסת ניתוח תפקודי 183

הנדסת פירוק תפקודי Functional Decomposition העברה מהירה בטוחה ואמינה מנקודה א' ל-ב' אספקת מומנט 184 הנעה שליטה בהספק עצירה אספקת אנרגיה הובלת אנשים שליטה במומנט ניתוח תפקודי היגוי הובלת מטען קשר לכביש טיפול בסביבת הרכב להיכן לשייך דרישות הקטנת פליטת גזים דרישות תאורה דרישות נוחיות ישיבה? דרישות מרחב? דרישות בטיחות? דרישות מבנה? עיצוב הרכב

תהליך הפירוק התפקודי הנדסת ניתוח תפקודי 185

תרגום דרישה מערכתית גורמים משפיעים תכונות המטרה תנאי ראות התנהגות האטמוספרה עבירות אור הגדלה כושר הפרדה MRTD/MTF/ טווחי רכישה רגישות הגלאי/גודל פיקסל יחס אות לרעש תכונות הצגת התמונה החלטות סוג הגלאי ותכונותיו סוג הטלסקופ ומימדים צורת זיווד חומרים אופטיים מעגלי רכישת התמונה מעגלי עיבוד אות מעגלי ע"ת סוג הצג וגודלו הנדסת לכל אחד מהפרמטרים קיימת נקודת עבודה, המשפיעה על סביבתו. תמיד יש נקודת עבודה מיטבית שהיא טובה מהאחרות קיים גם אופטימום מערכתי כולל שאינו מורכב בהכרח מהנקודות המיטביות הבודדות ניתוח תפקודי 186

סיכויי פגיעה תרגום דרישה מערכתית גורמים משפיעים דיוק כינון דיוק חישוב דיוק חליפה בליסטי דיוקי סנסורים מטאו דיוק ת.כ. יציאה מת.כ. בתנ"ס דיוק שיעבוד תותח ל- LOS דיוק פגז ידני עקיבה אוט' קפיצת קנה, שחיקת קנה החלטות דיוק אלגוריתם עוקב, בליסטיקה, חליפה דיוקי ייצוב LOS דיוק סנסורים מטאו דיוק רזולברים הנדסת דיוק וניצבות ציר האצילים דיוק החישוב הבליסטי לכל אחד מהפרמטרים קיימת נקודת עבודה, המשפיעה על סביבתו. תמיד יש נקודת עבודה מיטבית שהיא טובה מהאחרות קיים גם אופטימום מערכתי כולל שאינו מורכב בהכרח מהנקודות המיטביות הבודדות ניתוח תפקודי 187

מהו ניתוח תפקודי? פירוק המערכת לרכיבים המתאימים לתפעול המערכת ותת המערכת. (IEEE 610.12-1990) חלוקת כל פונקציה )תפקוד( למרכיביה: ABCD AB CD ו- CD. AB מתפרק ל- ABCD B ו- ממשיכה להתפרק ל- A AB D ו- מתפרקת ל- C CD הנדסת A B C D יחסי אב-בן כל התפקודים )הפונקציות( והתהליכים מקושרים לתפקוד או לתהליך אחד לפחות. לכל אב יש לפחות שני ילדים. לכל ילד יש רק אב אחד יש ילדים "יתומים" כאשר התפקוד נובע מדרישת חוק, תקנה או דרישת רישוי ניתוח תפקודי 188

מודלים פיזיקאליים ולוגיים להפשטה הערכה כמותית של מימדי ה. מימדים פיזיקאליים, אנרגיות, הספקים מודלים לוגיים )אלגוריתמים למיניהם( חוקי טבע )פיזיקה, כימיה( המבטאים את משימת המערכת הנדסת דוגמה: ברז אמבטיה תפקודים מערבב מים חמים וקרים מודד טמפרטורת המים מודד ספיקת מים )קצב הזרימה( מכוון טמפרטורת מים מכוון ספיקת מים עוצר את זרימת המים מקור: הרצאה של דרורה גושן 24.3.2012 ניתוח תפקודי )תרמוסטטי( שמבקר טמפרטורת מים V T out out V V HOT HOT V T V COLD HOT HOT V V COLD COLD T COLD Where: T=Temperature V=Water Volume=Flow Rate/Time Or Volume Flow rate 189

הנדסת תרשים זרימה תפקודית )Functional Flow Block Diagram( קורס הנדסת Source: HDI Functional Analysis, Optimizations and Implementation Trade-offs, IMCO 190

מודלים פיזיקאליים ולוגיים להפשטה הנדסת Sequence Diagram Use Case Diagram example ניתוח תפקודי 191

תרגיל: הרחב את רשימת התפקודים מנהל החברה מצא שהוצאות הטלפון של החברה מרקיעות שחקים. הוא מינה צוות שימצא דרכים לצמצום חשבון ההוצאות. ראש הצוות )אתה( החליט בצע ניתוח תפקודי ולנסות לאתר תחליפים טכנולוגיים שיאפשרו לצמצם את הוצאות הטלפון מבלי לפגוע בתפקוד חברה או בעובדיה. הנדסת תרגיל: מהם תפקודי הטלפון. מצא תחליפים טכנולוגיים. ניתוח תפקודי - 192-192

שיטות לפירוק תפקודי פירוק תפקודי יכול להיות מוצג כהיררכית המערכת, סכמת בלוקים תפקודית, סכמת זרימה תפקודית,,time lines דיאגרמת זרימת נתונים/בקרה, או דפי הקצאת דרישות )Functional Analysis System Technique( טכניקת FAST מבוססת על לוגיקת השאלות "איך" ו"למה" שיטת יורדון )Yourdon Methodology( מבוססת על דיאגרמות זרימת המידע ( diagrams )data flow אשר מתארות את תנועת המידע ותוכנן בין מרכיבי המערכת ו"מילון" מידע dictionary( )data שמתאר את תוכן המידע. מתאים בעיקר ל עתירות מידע או תוכנה דיאגרמות תפקודים עוקבים Charts( )Sequential Function או SFC או Grafcet מבוססת על ניתוח הצעדים )שמתארים פעילויות בקרה( ומעברים המתארים פעילויות בין הצעדים. מתאים במיוחד ל בקרה או שפועלות בסדר קבוע עתירות נתונים שכוללות סדר פעולות מורכב, יכולות להשתמש בשתי השיטות הנ"ל גם יחד או בשיטה המשלבת את שתיהן Requirements State Machine Language RSML תכנון מבוסס מצבים מאוגד למצבי על בעזרת דמיון במעברים. המערכת יורד משמעותית פירוק תפקודי היררכי במקרה של תיכון סימטרי שניתן לתאר אותו בעזרת עץ ושיטות רבות אחרות במצב זה מספר מצבי הנדסת ניתוח תפקודי 193

הנדסת ניתוח תפקודי בטכניקת FAST Functional Analysis System Technique ניתוח תפקודי 194

טכניקת FAST Functional Analysis System Technique ארגן את התפקודים כתפקודים בסיסיים ו תומכים: תפקודים בסיסיים )ראשיים( חייבים להתממש תומכים )משניים( אחרים. יכולים לתמוך בתפקודים הבסיסיים ארגן על פי יחסי "איך", "למה", "מתי" במיון של צרכי בעלי העניין יש להוסיף גם את ה התומכים שחיוניים לאישור המערכת על ידי הלקוח. אין לערבב תפקודים המבוצעים ע"י המשתמש, המתכנן או היצרן הנדסת ניתוח תפקודי 195

196 נוחות פעולה סיוע בתחזוקה ותיקונים מתן הנחיות והוראות למשתמשים מהימנות פעולה חוזק פיזי של מבנה המערכת הגנת המשתמש )בטיחות( מהם תומכים הגדלת אורך מחזור החיים, הקטנת הצורך בתחזוקה שיפור אמינות הגנת הסביבה הבטחת שביעות רצון הלקוח שיפור תפקודים בסיסים )מהר יותר, קטן יותר, מדוייק יותר וכו'( נוחיות פיזית למפעיל )ארגונומיות( קלות פעולה שיפור סביבת העבודה )כמו הפחתת הרעש, קרינה וכו'( אטרקטיביות ללקוח צורה נאה של המוצר שיפור תחושת הביטחון של המשתמש )שימוש בסמלים מתאימים, שימוש בציוד מוכר למשתמש, שימוש במצאי חלקי חילוף קיים לצורך תחזוקה וכו'( שימוש בחומרים או תכנונים המועדפים על ידי הלקוח ניתוח תפקודי הנדסת

הנדסת תרשים FAST איך? תפקודי פעולה תפקוד בסיסי עידון ה למה? תפקודי תפקוד משימתי תפקוד בסיסי תומכים נוחות הפעלה תחזוקה תיקון ספרות תחזוקה מהימנות פעולה בטיחות אמינות ניתוח תפקודי שביעות רצון לקוח אטרקטיביות ללקוח בטיחות אמינות פשטות הפעלה 197

תרשים FAST של עיפרון הנדסת HOW WHY Display Information WHEN Improve Appearance Record Information Make Marks Deposit Medium Apply Preassure Support Lead Protect Wood Keep Records Maintain Information Secure Eraser Transmit Force Accommodate Grip Hold Pencil Correct Information Remove Marks Absorb Medium Apply Preassure Source: Value Analysis and Function Analysis System Technique, Kenneth Crow DRM Associates, 2002 Rub Eraser ניתוח תפקודי 198

איך? תפקודי נידות ועבירות זריזה דוגמה לתרשים -FAST קורקינט תפקודים בסיסיים יכולת תנועה ועבירות תומכים אטרקטיביות ללקוח אמינות ובטיחות יכולת מעבר בשבילים כבישים יכולת עליה וירידה על מדרכות יציבות ותחושת ביטחון לנוסע נוח לנשיאה )בתחבורה ציבורית( אפשרות לקיפול מאפשר עליה לתחבורה ציבורית נוח לנשיאה )בהליכה רגלית( יכולת הוספת מושב קל משקל אמינות ואיכות המרכיבים מתוכנן בצורה בטיחותית מתאים גם לילדים ונערים יכולת פשוטה לבדוק תקינות הנדסת למה? עלות ואסטטיקה מחיר נמוך מהמתחרים בלאי נמוך חלקי חילוף זולים וזמינים נאה למראה, "מקצועי" ניתוח תפקודי 199

דוגמה: ניתוח צרכי בעלי העניין של מברגה נטענת Rechargeable Screw Driver צרכי בעלי העניין למברגה הנטענת תספק כוח רב להברגת ברגים תהיה קלה להכנה ולשימוש כח המברגה יהיה זמין תחזיק מעמד זמן רב תוכל להבריג את רוב סוגי הברגים תוכל להבריג גם ברגים במצב גרוע תהיה קלה לאיחסון תשב טוב ביד המשתמש תהיה קלה לבקרה בזמן ההברגה תמנע נזק לעבודה לא תרעיש בזמן הפעולה תראה ככלי מקצועי איכותי הנדסת הערה-התרגום במצגת הוא בתרגום חופשי ניתוח תפקודי 200

פירוט צרכי בעלי העניין של המברגה המברגה תספק כוח רב להברגת ברגים הנדסת תיעדוף * ** *** * * * * * *!* המברגה תאפשר עבודה מאומצת למשך מספר שעות המברגה תוכל להבריג ברגים בעץ קשה המברגה תאפשר הברגת ברגי פח לצינורות מתכתיים המברגה תבריג מהר יותר מאשר בהברגה ידנית המברגה תהיה קלה להכנה ולשימוש המברגה תהיה קלה להפעלה המברגה תמנע כיבוי לא רצוי המפעיל יוכל לווסת את המומנט המירבי של המברגה המברגה תאפשר גישה נוחה לביטים ואביזרים המברגה תוכל להיות קשורה למשתמש לצורך אחסון זמני המברגה תאפשר התחלה קלה של הברגות המברגה תחזיק את הבורג לפני ההברגה המברגה תאפשר ליצור חור מוביל לבורג ניתוח תפקודי 201

כח המברגה יהיה זמין פירוט צרכי בעלי העניין של המברגה הנדסת תיעדוף * ***!*** ** * ** המברגה תהיה קלה לטעינה אפשר יהיה להשתמש במברגה בזמן הטעינה המברגה תיטען במהירות סוללות חדשות יהיו מוכנות לשימוש המברגה תוכל לספק מומנט ידני לצורך הובלת הבורג המברגה תחזיק מעמד זמן רב חוד )טיפ( המקדחה ישרוד בעומס כבד המקדחה תוכל לעבוד במצב "פטיש" המקדחה תוכל ליפול מסולם מבלי להינזק המקדחה תוכל להבריג את רוב סוגי הברגים המקדחה תוכל להבריג ברגים גם לחורים צרים וארוכים המברגה תוכל להבריג גם ברגים במצב גרוע המקדחה תוכל לשמש גם להורדת לכלוך וגריז מהברגים המברגה תוכל להבריג גם ברגים צבועים ניתוח תפקודי 202

פירוט צרכי בעלי העניין של המברגה המברגה תהיה קלה לאיחסון הנדסת תיעדוף * ** * *** *** *! תתאים בקלות לארגז כלים תתאפשר טעינת המברגה גם בעת אחסנה המברגה לא תחליד גם אם תאוחסן במקומות לחים המברגה תישאר טעונה גם לאחר איחסון ארוך המקדחה תשמור על הטעינה גם ברטיבות המקדחה תשב טוב ביד המשתמש המברגה תהיה נוחה כשהמשתמש לוחץ עליה בכיוון ההברגה המברגה תהיה נוחה למצב בו יש התנגדות להברגה המברגה תהיה מאוזמת ביד המשתמש המברגה תהיה נוחה לשימוש גם משקל המקדחה יהיה מתאים המקדחה תהיה חמה למגע במזג אוויר קר ביד ימין וגם ביד שמאל המקדחה תישאר נוחה לשימוש גם אם הושארה בשמש ניתוח תפקודי 203

פירוט צרכי בעלי העניין של המברגה המברגה תהיה קלה לבקרה בזמן ההברגה הנדסת תיעדוף *** ***!** * ** * * * * * המשתמש ידחוף בקלות את המברגה המשתמש יתנגד בקלות לפיתול המברגה אפשר לנעול את מצב ההפעלה של המברגה המשתמש יוכל לשנות את מהירות המברגה בזמן ההברגה המברגה תשאר מכוונת עם ראש הבורג ללא החלקה המשתמש יוכל לראות בקלות היכן הבורג המברגה לא תקלף את ראש הבורג אפשר יהיה לשנות את כיוון ההברגה אחורה/קדימה בקלות המברגה תמנע נזק לעבודה המברגה תמנע נזק לראש הבורג המברגה לא תשרוט את משטח העבודה המברגה תהיה בטוחה המברגה לא תאפשר התחשמלות המשתמש המקדחה לא תחתוך את יד המשתמש ניתוח תפקודי 204

פירוט צרכי בעלי העניין של המברגה המברגה לא תרעיש בזמן הפעולה המברגה תראה ככלי מקצועי איכותי הנדסת תיעדוף ניתוח תפקודי 205

דיאגרמת FAST 206 איך? תפקודי הברגת ברגים תפקודים בסיסיים תספק כוח רב תסייע לתחילת הברגה מבריגה ברגים במצב גרוע תאפשר בקרת מומנט תומכים מהימנות פעולה נוחות הפעלה לקוח רצון שביעות אטרקטיביות ללקוח ניתוח תפקודי למברגה נטענת מחזיקה את הבורג לפני ההברגה מאפשרת קידוח חור מוביל בטוחה לעבודה מחזיקה זמן רב קלה לתיקון ספרות תחזוקה פשטות הפעלה מתאימה לרוב הברגים יושבת טוב ביד קלה לאחסון הכוח יהיה זמין שקטה מראה מקצועי ואיכותי הנדסת למה? לא תאפשר התחשמלות המשתמש לא תחתוך את יד המשתמש קלה לשליטה ובקרה קלה להכנה ולשימוש טעינה נוחה טעינה מהירה אפשר להשתמש בזמן טעינה סוללות חדשות יהיו מוכנות לשימוש אפשר לספק מומנט ידני הטעינה

207 איך? ניידות עצמית בסביבה קרובה בסיסיים ומובנים: מהירות הרכבה סבירה מהירות נסיעה סבירה בלימת זעזועים Source: INCOSE_IL SysE for SME Meeting. Dr. Drora Goshen 12-3-12 דוגמה לעץ הנדסת למה? ניידות עצמית ניידות עצמית ל יומיומיים, ל סיעודיים/רפואיים ל שונים ניידות עצמית לצרכי שיפור תרבות הפנאי, למטרת נשיאת ציוד ניידות עצמית למטרת תעסוקה ולמטרת תחליף רכב גדול ניידות עצמית ניידות עצמית של מבוגרים, הורים ועובדים מהבית לבעלי עניין שונים ניידות עצמית של בני נוער, בעלי מקצוע ולצורך אחזקה בטוח לשימוש יציב בעל מנגנוני אבטחה ובטיחות ניתן לשליטה גם במצבי קיצון נוח וקל לתפעול הנדסת אנוש וממשק משתמש ידידותיים מצריך מינימום פעולות להפעלה אחסון מהיר יכולת תנועה עבירות בדרכים אופייניות: כבישים, מדרכות, דרכי עפר, דרכים משובשות ועבירות ביצוע פעולות מיוחדות: עליה וירידה ממדרכות, תנועה במעברים צרים ובשיפועי צד תנועה בפארקים ומגרשי גולף אסטטיות, יכולת אביזרי נוחות, אביזרים סיעודיים, אביזרים לנשיאת ציוד שדרוג והוספת כיסויים לחורף אביזרים החלפת מושבים מעובי בודד לכפול, אפשרות לחיבור נגררים אביזרי יוקרה ו"צעצועים" אמינות אמינות גבוהה, פשוט וקל לתחזוקה ותחזוקתיות מינימום אחזקה בדרג מפעיל, איתור וזיהוי תקלות מהיר בדרג המפעיל קיום מערך תחזוקה עלות מתאימה מתאים ללקוחות מהמעמד הבינוני ומעלה הפעלה זולה בעלות מינימאלית, תחזוקה זולה התאמה כלכלית אישית ותנאי תשלום ניתוח תפקודי

טכניקות תיעדוף הנדסת NGT or 100-point method (100P) or Cumulative voting Quality Function Deployment (QFD) Cost-Value Approach (CVA) Binary Search Tree (BST) Planning game (PG) (iterative) PROMETHEE (multi-criteria) EVOLVE Value Oriented Prioritation Method (VOP) Minimal Spanning Tree (MST), Bubble Sort (BS), Numeral Assignment ניתוח תפקודי 208

תיעדוף צורכי הלקוח / דרישות / מפרטים בעזרת טכניקת NGT בחירת ה/הדרישות/המפרטים שנראים ראויים להשוואה קיום הצבעה של קהל רלוונטי עם שקלולים בהתאם לחשיבות חוות הדעת של המצביע הנדסת Customer # need Voting Weight David 1 Shai 1 John 1 Josef 3 Amnon Shimon 3 1 Alex 1 Ron 2 AVG 13 STD DEV Decision 1 Cost 18 18 22 23 16 20 25 15 19 3.3 4 2 Weigh 25 20 15 33 25 20 24 20 24 5 5 3 Interface 8 17 10 5 8 10 5 14 9 3.9 2 4 Fast Location 4 4 5 2 3 5 3 2 3.1 1.1 1 5 User Friendly 22 15 20 15 20 25 30 25 21 4.8 4 6 Day/Night 13 16 23 13 18 10 8 13 15 4.4 3 7 Range 10 10 5 9 10 10 5 11 9.2 2.2 2 Total 100 100 100 100 100 100 100 100 100 NGT=Nominal Group Technique ניתוח תפקודי 209

הנדסת Cost-Value Approach A simple method for prioritizing product requirements The basic idea is to determine for each individual candidate requirement the relevant connected costs and to evaluate how much value the requirement has, using the Analytic Hierarchy Process (AHP). Then plot of these pairs on a cost-value diagram. Value is depicted on the y axis of this diagram and estimated cost on the x-axis. The stakeholders use the cost-value diagram as a conceptual map for analyzing and discussing the candidate requirements. Now software managers prioritize the requirements and decide which will be implemented. The planning process consists of the sub processes: Prioritize requirements Select requirements Define basic requirements Validate basic requirements Prepare launch קורס הנדסת ניתוח תפקודי 210

הנדסת ערך Cost-Value Approach החלטה חיובית לשיקול נוסף החלטה שלילית עלות יכולת יום-לילה עלות משקל טווח משך פעולה אמינות עם סוללה מבצעית בודדת יכולת אימון יכולת שידרוג זמן הגעה והדרכה לשוק בטיחות יכולת תצפית ומודיעין גבוהה ידידתיות למפעיל איכון מהיר ממשקים ל קיימות תחזוקתיות נמוכה יותר חשוב פחות חשוב ניתוח תפקודי 211

212 דוגמא: תוצאות קבוצת מיקוד למדי טווח צורך הלקוח חשיבות Best In Class.1 משקל )3 ק"ג גבול עליון( פעולה תחת לחץ/ידידותי למפעיל מחיר יכולת פעולה יום/לילה טווח התממשקות ל קימות איכון מהיר של מטרות ( Target )Locator משך פעולה עם סוללה בודדת אמינות מבצעית תחזוקתיות יכולת אימון והדרכה כושר שדרוג זמן הגעה לשוק יכולת תצפית למודיעין בטיחות LM, Thales Thales LM LM, Thales, BAE BAE LM, BAE Thales LM BAE BAE Thales - LM, BAE BAE Thales 10 9 9 9 8 8 7 7 7 6 6 6 5 4 3.2.3.4.5.6.7.8.9.10.11.12.13.14.15 ניתוח תפקודי הנדסת

213 הגדרה ראשונית של המוצר/המערכת בתחילת הגדרת המוצר, יש להתייחס לתכולה הכללית של המוצר/המערכת המיועדת )כגון שימוש ב לגסי, מכלולים, חלקים עיקריים או מיוחדים, שירותים, תהליכים( יש לציין מהם הנושאים החשובים במוצר הדורשים התייחסות מיוחדת לאפיין קונספטים מאולצים )ע"י טכנולוגיות או תקנות( זיהוי ראשוני של פערי הידע )פערים טכניים/טכנולוגיים, שיווקיים, הבנת תרחישי השימוש( אילוצי תקציב ולו"ז מסגרת תקציב הפיתוח מסגרת תקציב להערכות לייצור ועלות יעד של המוצר בייצור סדרתי יעדי לו"ז הפיתוח, הדגמים, הצגת המוצר בשוק, כניסה לייצור כמותי ואילוצי אספקה ללקוח הנדסת יש להתייחס לכמויות הצפויות של ייצור המוצר )כמות המטרה( וצרכי ההערכות לייצור אפקטיבי של כמויות אלה לבחון את היבטים אסטרטגיים לפתרון הטכנולוגי והשיווקי )מגזר שוק-,High end,low end הסכמי שת"פ, חוזים עם חברות אחרות, כגון שיווק והפצת המוצר, פיתוח של חלקים להם יש מיומנות ייחודית וכו'( יש להדגיש הנקודות החשובות מהיבט בעלי העניין ניתוח תפקודי

הנדסת 1.3.6 תרגום צרכי בעלי העניין לדרישות ניתוח תפקודי דרישות 214

הגדרת הדרישות מטרות הבנת צרכי בעלי העניין והמרתן לדרישות כמותיות, בנות מדידה תחילת גיבוש הארכיטקטורה והקונספט המערכתי תהליך ניתוח מבצעי וסביבתי הגדרת התפקודים )פונקציות( הגדרת הדרישות הכמותיות תוצרים תאור מבצעי מסמך דרישות בעלי העניין הנדסת ניתוח תפקודי דרישות 215

תהליך הגדרת דרישות בעלי העניין תפוקות מסמכי קונספטים דרישות בעלי העניין מדדי אפקטיביות ונתונים שלהם קריטריוני תיקוף מטריצת אימות הדרישות עקיבות הדרישות בקרים )Controls( חוקים ותקנות רלוונטיים תקנים תעשייתיים הסכמים תהליכים, נוהלים והנחיות פרויקטאליים פעילויות הגדרת ומיצוי דרישות בעלי העניין ניתוח ותחזוקת דרישות בעלי העניין מאפשרים )Enablers( מדיניות, תהליכים ונוהלים ארגוניים תשתיות ארגוניות תשתיות פרוייקטאליות כניסות מסמכי מקור צרכי בעלי העניין אילוצי הפרוייקט כולל עלות, לוח זמנים, ואילוצי פתרון הנדסת הנחיות ישימות ממסמכי המקור לאחר תמצות, הבהרה ותיעדוף תיאור ה של משתמשים ובעלי עניין אחרים או שירותים שהמערכת תספק Source: INCOSE, Systems Engineering Handbook v. 3.2.2, October 2011 ניתוח תפקודי דרישות 216

מסמכי קונספט תוצרי תהליך הגדרת ומיצוי הדרישות קונספט הייצור - תאור איך המערכת תיוצר, כולל ציון חומרים מסוכנים שמשמשים בתהליך קונספט האספקה - תאור כיצד המערכת תסופק ותותקן קונספט מבצעי )ConOps( - תאור כיצד המערכת פועלת מנקודת ראות המפעיל. ה- ConOps כולל את תאור המוצר, תמצית הדרישות, היעדים ומאפייני קהילת המשתמשים )מפעילים, ואנשי תחזוקה ותמיכה( קונספט התמיכה - תאור התשתית ושיקולי כח האדם לתמיכה במערכת לאחר אספקתה, כולל ציון הציוד, הנהלים, המתקנים, ודרישות הכשרת המפעילים קונספט הגריטה - תאור הדרך בא תוצא המערכת מהשרות, כולל גריטת חומרים מסוכנים שהיו בשימוש או נוצרו בעת פעולת המערכת דרישות בעלי העניין - מסמכים פורמאליים ומאושרים של דרישות אלו שיובילו את פיתוח המערכת, כולל פירוט היכולות מערכתיות הדרושות, תפקודים ו/או שירותים, איכות, תקנים ואילוצי עלות ולוח זמנים הנדסת ניתוח תפקודי דרישות 217

תוצרי תהליך הגדרת ומיצוי הדרישות מדדי צרכי האפקטיביות או מדדי האפקטיביות ( of Measures.)effectiveness-MOEs אלו הם מדדים "מבצעיים" של הצלחה בהשגת יעדי ה או היעדים המבצעיים, באווירת הפעולה המיועדת ובמסגרת מגבלות התפעול )כלומר, כמה טוב הפתרון משיג את התכלית המיועדת( נתוני - MOE פירוט הנתונים שמסופקים למדידת ה- MOE קריטריוני תיקוף Criteria( )Validation - פירוט של מי מבצע את פעולות התיקוף וסביבת העבודה של מערכת היעד מטריצת אימות דרישות ( Matrix- Requirements Verification )RVM ראשונית - רשימת דרישות ומאפייני האימות שלהם עקיבות דרישות בעלי העניין - ציון הקשר הדו-כיווני של כל דרישות בעלי העניין, מצד אחד למקור שלהם כגון מסמך המקור או צורך בעלי הענייןומצד שני לנגזרות המפרטות אותם )כגון מפרטים( הנדסת ניתוח תפקודי דרישות 218

אז מה זו דרישה? דרישה: ביטוי בר בדיקה,)Verifiable( המתאר תכונה, יכולת או תפקוד של המערכת או מה שמשפיע על המערכת אנו מבחינים בין 3 רמות של הגדרת דרישות: צרכי בעלי העניין )הדרישה המבצעית( - תאור צרכי בעלי העניין במונחים תפעוליים מבצעיים צרכי בעלי העניין:, מעוניינים לפתח עבור מכונית הונדה לג'נד מערכת בטיחותית שתאפשר ראיית אדם בלילה מעורפל במרחקי נהיגה דרישות בעלי העניין - פירוט הדרישה המבצעית במונחים טכניים, בשפתו, במונחים ברי מדידה, שיאפשרו בעתיד לקבל את המערכת דרישת בעלי העניין: הכרת אדם במרחק של 50 מ' לפחות, בעבירות אטמוספרית אטמוספרית של פחות מ- 3%, בתאורת סביבה שקטנה מ- 100 מיקרולוקס מפרטי פיתוח - פירוט, בשפת המפתח, של הדרישות שנגזרות מהאופיון, שמאפשרות הגדרה חד משמעית של תוצרי הפיתוח ובדיקתם מפרט פיתוח: מערכת צילום תהיה בעלת MTF גדול מ- 10% ב- 25 זוגות קווים למילירדיאן בשדה ראיה של 30, ויכולת ההבחנה התרמית תהיה טובה מ-,50m K כאשר הרעידות בנקודת הדפינה יהיו קטנות מ- 1G RMS בתחום תדרים של 0.5 עד 350 הרץ. הנדסת ניתוח תפקודי דרישות 219

220 תכולת דרישות בעלי העניין דרישות הפרויקט תכולת הפרויקט והעבודה, קב"מ עיקריים, אבני דרך, לוחות זמנים, מגבלות משאבים דרישות ה requirements( )Mission היישום התפעולי - היכן כל מרכיב מערכתי ישמש פרופיל או תרחיש - איך המערכת תבצע ותשלים את יעדי ה פרמטרים תפקודיים - מהם הפרמטרים הקריטיים לביצוע ה סביבת השימוש - איך ישתמשו ברכיבי המערכת השונים דרישות יעילות - עד כמה המערכת נדרשת להיות אפקטיבית בביצוע ה אורך החיים התפעולי - כמה זמן המערכת תשמש את המשתמשים סביבת העבודה באיזו סביבה המערכת נדרשת לפעול בצורה אפקטיבית דרישות תפקודיות )פונקציונאליות( "מה המערכת צריכה לעשות". תיאור תפקודי המערכת ומרכיביה, כולל חישובים, פרטים טכניים, נתונים ומידע, עיבודם והעברתם בין המכללים השונים ופירוט שמגדיר מה המערכת צריכה לעשות ומהן תכולות התפוקות ממשקים חיצוניים, סביבת המערכת ודרישות לא פונקציונאליות "איך המערכת צריכה להיות". קריטריונים לתקינות הפעולה של המערכת, כגון בטיחות, שימושיות, בדיקתיות ותחזוקתיות אילוצים שציין הלקוח סוגיות לא ברורות שהתגלו בזמן ניתוח הדרישות ומסלול פתרונן תהליכי האימות והתיקוף שנדרשים על ידי הלקוח עקיבות הדרישות ניתוח תפקודי למקורם דרישות הנדסת

דרישות ה סוגי דרישות בעלי העניין )1/3( )Mission requirements( הנדסת דרישות המגדירות נושאים שהם קריטיים להצלחת משימות המערכת היישום התפעולי - היכן כל מרכיב מערכתי ישמש פרופיל או תרחיש - איך המערכת תבצע ותשלים את יעדי ה דרישות יעילות מדדים של עד כמה המערכת נדרשת להיות אפקטיבית בביצוע ה נושאים שדורשים התייחסות חריגה, כגון תנאי סביבה, חסינות מתקלות, יציבות וכו' דרישות תפקודיות )Functional requirements( פירוט תפקודי המערכת או התנהגותה, דרישות ביצועים )Performance requirements( כפי שנראים בעיני משתמש חיצוני פירוט כמותי של המדדים הטכניים של המערכת ו/או יעילותה, שנדרשים למימוש הדרישות התפקודיות ודרישות ה דרישות לא תפקודיות )non-functional requirements( תכונות התנהגות האופייניות לתפקודים המלווים את המערכת, כגון: תנאי סביבה בפעולה, בהמתנה, באחסון וכו' אמינות וזמינות על פי פרופיל פעילות אחזקתיות ובדיקתיות )דרגי תחזוקה, שיטה,,BIT משכים, תשתיות, ציוד, ח"ח( בטיחות, שרידות, שימור הסביבה, חומרים, אריזה, גריטה, Interoperability אריזה, משלוח, אחסון, ושינוע, תיעוד ספרות ומסמכים דרישות כ"א לניהול, הפעלה, הדרכה, תחזוקה, דרישות הכשרה, קורסים ניתוח תפקודי דרישות 221

דרישות ממשקים סוגי דרישות בעלי העניין )2/3( )Interface requirements( תיאור דרכי חיבור וקישור המערכת לסביבתה ממשקים חיצוניים פיזיים ולוגיים, ממשקי התקנה ממשקים חשמליים )אספקות, אותות, תזמונים, כבלים, רגישות לקרינה והולכה( ממשקים מכניים ואלקטרו-מכניים )סטטיים קינמטיים, דינאמיים, ייצוב, שיעבוד( ממשקי תוכנה )פרוטוקולים, תקשורת, קודים, זמני תגובה, ספיקת אותות( ממשקים אופטיים וממשקי וידאו דרישות תפעול )Operational requirements( הנדסת,HMI מסכים והפעלתם, ארגונומיה, הנדסת גורמי אנוש, קלט ופלט של נתונים ותנועתם במערכת ניתוח תפקודי דרישות 222

אילוצים מערכתיים סוגי דרישות בעלי העניין )3/3( )Constrains( הנדסת אילוצים על תכן המערכת, כגון עלויות, לוחות זמנים, שימוש ב- COTS, שימוש ב- NDI, שימוש בתשתיות קיימות, מגבלות פיזיות, חומרים וכו'. אילוצים על תהליכי האינטגרציה והאימות, כגון בטיחות, תשתיות, סוגי ניסויים, יכולת מדידה וכו' אילוצים על העברת המערכת transportation( )System, כגון נפחים, אמצעי דפינה, אריזות הסעה וכו' אילוצי תפעול, כגון תרחישי ייחוס, ממשקים תפעוליים, מגבלות זמן תפעול, אבטחת נכונות הנתונים בכניסות וביציאות, רמות איוש תפעולי, ביטחון אילוצים שנובעים ממגבלות חוקיות או תקנות, מגבלות לוגיסטיות )ניקיון רכיבים( ומגבלות תהליכיות מגבלות על תחזוקת המערכת, כגון סוגי תשתיות, סוגי ציוד, רמות איוש, הכשרה מגבלות על גריטת המערכת, כגון חומרים מסוכנים, תהליכי פירוק, Reuse וכו' סוגיות לא ברורות שהתגלו בזמן ניתוח הדרישות ומסלול פתרונן תהליכי האימות והתיקוף שנדרשים על ידי הלקוח עקיבות הדרישות למקורם TBR,TBD( וכו'( ניתוח תפקודי דרישות 223

הבנת דרישות בעלי העניין הנדסת כך הסביר את זה הלקוח כך הבין את זה מנהל הפרוייקט כך תכנן את זה המתכנן כך כתב את זה המתכנת כך תאר את זה היועץ העסקי כך תועד הפרויקט זה מה שהותקן כך נדרש הלקוח לשלם כך נראתה התמיכה זה מה שהלקוח באמת היה צריך ניתוח תפקודי דרישות 224

225 דרישות בעלי העניין הגדרת ה"מה" מכילות תיאור מדויק של המערכת אותה צריך לבנות במונחי הלקוח. נכתבות בשפה טכנית בתבנית רשמית. משמש כבסיס לחוזה בין הרוכש, והמפתח. דרישות בעלי העניין יהיו כתובים במונחים של תוצאות נדרשות עם קריטריונים לוודא התאמה,)compliance( אך ללא פירוט השיטות להשגת התוצאה הנדרשת. יש לשמור על הכללים הבאים: יש לכלול רק דרישות הכרחיות, מדידות, בנות ביצוע, בדיקה אובייקטיבית. הניסוח צריך להיות כזה שיהווה בסיס מוצק להסכמה או דחיה. הניסוח יהיה כך שכל פסקה תתאר דרישה אחת בלבד הניסוח יהיה כזה שיובן באופן חד ערכי על ידי כל הצדדים הרלוונטיים מכלול הדרישות יהיה מינימאליסטי )רק מה שבאמת צריך( הדרישות יכתבו במונחים של תוצאות נדרשות הדרישות יכללו קריטריונים לבדיקת התאמה )compliance( סט הדרישות יהיה שלם ככל האפשר וללא סתירות םנימיות הדרישות לא יכללו פירוט השיטות להשגת התוצאה הנדרשת. ניתוח תפקודי דרישות ושניתן לוודא אותן ע"י הנדסת

דוגמאות שליליות לדרישות דוגמאות לדרישות שגויות )איך ולא מה(: "איך" ולא "מה" הנדסת titanium case titanium or Kevlar (red or black) strap liquid-crystal display lithium battery Discovering System Requirements, Terry Bahill, University of Arizona ניתוח תפקודי דרישות 226

לניתוח צרכי בעלי העניין הנדסת מודל Kano לינאריים מלהיבים שביעות רצון הלקוח מאוד מרוצה מידת השגת הביצועים הושג במלואו לא הושג בסיסיים מאוד לא שבע רצון ניתוח תפקודי דרישות זמן 227

חדשנות בשוק... הנדסת ניתוח תפקודי דרישות 228

בדיקות תיכון מהו ניהול דרישות? גזירה גזירה מיון ואירגון הנדסת איסוף ומיצוי דרישות קשורות מה לא בסדר? דרישות נסתרות מפרטי בדיקה מסמכי התיכון ביטול כפילויות, עקביות, שלמות אחד שמגיע מאוחר יותר דרישה שלא מולאה מפרטי מרכיבי מערכת מפרט מערכת דרישות בעלי העניין ניתוח תפקודי דרישות 229

מקורות לדרישות בעלי העניין הנדסת Source: INCOSE, Systems Engineering Handbook v. 3.2.2, October 2011 ניתוח תפקודי דרישות 230

הנדסת 1.3.7 כתיבה נכונה של דרישות ניתוח תפקודי דרישות 231

ע"י שינוי מיקום המילה חשיבות הניסוח "רק" ניתן לקבל 5 משמעויות שונות: הנדסת רק אני לקחתי אותה אתמול לגן אני רק לקחתי אותה אתמול לגן אני לקחתי רק אותה אתמול לגן אני לקחתי אותה רק אתמול לגן אני לקחתי אותה אתמול רק לגן ניתוח תפקודי דרישות 232

הנדסת The importance of Attitude An English professor wrote on the chalkboard the words: A woman without her man is nothing and asked his students to punctuate it correctly. קורס הנדסת All of the males in the class wrote: A woman, without her man, is nothing. All the females in the class wrote: A woman: without her, man is nothing. ניתוח תפקודי דרישות 233

שוב-נקודת המבט לפני זמן מה קיבלתי הזמנה לקורס "ניהול זמן אפקטיבי" השאלות: מה כאן אפקטיבי=הזמן או הניהול. הכוונה ברורה אך הניסוח לא! איך מנסחים נכון את קטע המשפט? יכול להיות שניהול אפקטיבי של זמן יותר מתאים כאן? הנדסת ניתוח תפקודי דרישות 234

235 כתיבה נכונה של דרישה/מפרט ניסוח דרישה/מפרט צריך להוות בסיס מוצק להסכמה או דחייה דרישה "טובה" צריכה להיות מנוסחת כך שהיא: נחוצה- מתארת צורך ממשי אין אפשרות לענות לצורך מבצעי בלעדיה ייחודית לא חופפת עם אף דרישה אחרת לא סותרת אף דרישה אחרת מתומצתת וברורה לכל קורא מנוסחת בפשטות ואינה משתמעת לשני פנים שלמה מנוסחת באופן שלם, ניתן למדידה ולכלול מספיק יכולות או מאפיינים עקבית מנוסחת במישור של שאר הדרישות איננה מופיעה יותר מפעם אחת לא סותרת אף דרישה אחרת בת השגה אפשרית מבחינה טכנית, כלכלית, לו"ז והאילוצים הטכניים דרישות ניתוח תפקודי עקיבה )Traceable( שמקורה ידוע בת אימות-אפשר לבדוק אותה כתובה במונחים של תוצאות דרושות הנדסת כוללת קריטריונים לבדיקת התאמה )compliance( אינה משתמעת לשני פנים מונחיה מוגדרים בצורה מספקת יחידה כל דרישה תתאר תפקוד אחד כל פסקה תכיל דרישה אחת ניתנת להקצאה ניתן להקצותה למרכיבי הארכיטקטורה לא כוללת דרך מימוש "איך" לא "מה", רק

236 מבנה המשפטים קצר ופשוט התייחס למערכת, לא למפעיל השתמש בזמני פו ע ל כדלהלן: "shall" מציין מפרט מחייב )is required( "will" מסמן את כוונת הכותב כתיבה נכונה של דרישה/מפרט "should" מציין עדיפות, כהמלצה, על כמה אפשרויות אחרות ) is reccomended that( "Can" משמעו "יכול" או "מסוגל" to( )is able "may" - רשאי בגבולות המפרט )is premitted to( "must" מעורפל עם מס' מובנים )"John must love Mary"( המנע "משינויים אלגנטיים" בניסוח השתמש תמיד באותה צורת ניסוח המנע מייחוס למסמכים חיצוניים, אלא אם חובה לעשות זאת - ובדוק אותם... אין להשתמש בראשי תיבות, שלא מוכרים בודאות לכל בעלי העניין ניתוח תפקודי דרישות הנדסת המנע מהכללת יתר "Always, Every, all, None "As much as possible, Never אין להשתמש במושגים מופשטים,"like the, suitable, and/or, best, etc.,"first rate, adequate and others", i.e., e.g.,"most המנע מניסוחים סובייקטיביים "cost,"easy to use,"user friendly" "provide,"if possible,effective" "better than "but not limited,support" "higher quality "as a minimum "as,to appropriate, "as applicable" מנע ניסוחים בעלי מס' משמעויות,"significant","almost always, real time, timely,"minimal", appropriately, precisely, multiple, various, approximately accordingly, limited, few, many כל סעיף שכולל TBR,TBD וכו', חייב להופיע ברשימת ה- Issues

כתיבה נכונה של דרישה/מפרט הנדסת התמקדות במטרות התכנית אין להרחיב, אלא אם ההרחבה היא יעד של הפרוייקט " עודף" דרישות גרוע כמו חוסר. יש דרישות שעדיף להציג בעזרת איורים. בסיסי נתונים יעילים עקב שלמות המידע הכלול בהם, חשיפת מידע זהה לכלל המשתמשים, יכולת הקישור בין הפריטים, וכן יכולת מיון וסינון הפריטים מצד שני, בסיסי נתונים עלולים להיות מסוכנים בכך שהם יכולים לזמן יותר מידע ממה שבאמת נחוץ. "Between thought and expression there lies a lifetime Bob Dylan ניתוח תפקודי דרישות 237

)לא( כתיבה נכונה של דרישה/מפרט הנדסת ניתוח תפקודי דרישות 238

)לא( כתיבה דוגמאות לדרישות שגויות נכונה של דרישה/מפרט "מה"( ולא )"איך" הנדסת Titanium case Titanium or Kevlar (red or black) strap Liquid-crystal display Lithium battery Source: Discovering System Requirements, Terry Bahill, University of Arizona ניתוח תפקודי דרישות 239

טעויות נפוצות בהגדרת דרישות הנחות שגויות פתרונות )"איך"( במקום דרישות )"מה"( תיאור פעולות במקום דרישות שימוש במונחים לא נכונים שימוש במבנה משפט לא נכון או דקדוק גרוע דרישות חסרות דרישות יתר )Over-specifying( ע"פ איבי הוקס הנדסת ניתוח תפקודי דרישות 240

.1.2.3.4.5.6.7.8.9 תכולת הדרישות דרישות פרויקט דרישות ה אילוצי הלקוח דרישות ממשקים, סביבה, ודרישות לא תפקודיות ציון של נושאים )Issues( לא ברורים שהתגלו בתהליך ניתוח הדרישות תוצאות ניתוח הנושאים שהועלו וההחלטות שהתקבלו שיטות אימות ותיקוף שנדרשות על ידי הלקוח עקיבות לתיעוד המקור הוכחה )אימות( שבסיס הנתונים הוא פירוש תקף של צרכי משתמש הנדסת ניתוח תפקודי דרישות 241

תבנית נכונה לכתיבת דרישה הנדסת Requirement ID: Requirement Content Requirement V & V method: Requirement Priority: Requirement Users: Requirement Application: Requirement V & V stage: Requirement Source: Requirement Dependencies: Requirement Conflicts: Comments: Unique identifier A measurable statement of the requirement, written following the writing rules. Analysis, Inspection, System Test, Component Test Safety, Key, Mandatory, Optional, Desirable A list of disciplines that are influenced by the requirement A list of system s units that are influenced by the requirement According to the project life cycle Stakeholder s Name, End user, Derived from doc ID, Standard With other requirement that have an impact on this requirement With other requirement that have an impact on this requirement ניתוח תפקודי דרישות 242

דוגמאות לכתיבה דוגמה לדרישה לא טובה : המערכת תהייה ידידותית למשתמש )למה הכוונה? - מסג? 2 קפה? ( הנדסת דרישות נגזרות מ ידידותית למשתמש נוחיות הגישה לבקרים, להתקנה, לתחזוקה משוב תוך פחות מ- 0.1 שניה לכל פניה של המשתמש זמן תגובה מקסימלי לשינוי תצוגה )שלא יעצבן...( אינדיקציה דינמית על פעילות שאינה משנה תצוגה אי תקיע ות... גודל, מיקום וכיוון התצוגה ביחס לצופה עומס תצוגה...מינימיזציה הבחנה ברורה בין מצבים דומים מניעה מובנית של טעות הרכבה או הפעלה לא נכונה ניתוח תפקודי דרישות 243

הנדסת 1.3.8 סיווג הדרישות ניתוח תפקודי דרישות 244

דרישות ה סוגי הדרישות )1/3( )Mission requirements( הנדסת דרישות המגדירות נושאים שהם קריטיים להצלחת משימות המערכת היישום התפעולי - היכן כל מרכיב מערכתי ישמש פרופיל או תרחיש - איך המערכת תבצע ותשלים את יעדי ה דרישות יעילות מדדים של עד כמה המערכת נדרשת להיות אפקטיבית בביצוע ה נושאים שדורשים התייחסות חריגה, כגון תנאי סביבה, חסינות מתקלות, יציבות וכו' דרישות תפקודיות )Functional requirements( פירוט תפקודי המערכת או התנהגותה, דרישות ביצועים )Performance requirements( כפי שנראים בעיני משתמש חיצוני פירוט כמותי של המדדים הטכניים של המערכת ו/או יעילותה, שנדרשים למימוש הדרישות התפקודיות ודרישות ה דרישות לא תפקודיות )non-functional requirements( תכונות התנהגות האופייניות לתפקודים המלווים את המערכת, כגון: תנאי סביבה בפעולה, בהמתנה, באחסון וכו' אמינות וזמינות על פי פרופיל פעילות אחזקתיות ובדיקתיות )דרגי תחזוקה, שיטה,,BIT משכים, תשתיות, ציוד, ח"ח( בטיחות, שרידות, שימור הסביבה, חומרים, אריזה, גריטה, Interoperability אריזה, משלוח, אחסון, ושינוע, תיעוד ספרות ומסמכים דרישות כ"א לניהול, הפעלה, הדרכה, תחזוקה, דרישות הכשרה, קורסים ניתוח תפקודי דרישות 245

דרישות ממשקים סוגי הדרישות )2/3( )Interface requirements( תיאור דרכי חיבור וקישור המערכת לסביבתה ממשקים חיצוניים פיזיים ולוגיים, ממשקי התקנה ממשקים חשמליים )אספקות, אותות, תזמונים, כבלים, רגישות לקרינה והולכה( ממשקים מכניים ואלקטרו-מכניים )סטטיים קינמטיים, דינאמיים, ייצוב, שיעבוד( ממשקי תוכנה )פרוטוקולים, תקשורת, קודים, זמני תגובה, ספיקת אותות( ממשקים אופטיים וממשקי וידאו דרישות תפעול )Operational requirements( הנדסת,HMI מסכים והפעלתם, ארגונומיה, הנדסת גורמי אנוש, קלט ופלט של נתונים ותנועתם במערכת ניתוח תפקודי דרישות 246

אילוצים מערכתיים סוגי הדרישות )3/3( )Constrains( הנדסת אילוצים על תכן המערכת, כגון עלויות, לוחות זמנים, שימוש ב- COTS, שימוש ב- NDI, שימוש בתשתיות קיימות, מגבלות פיזיות, חומרים וכו'. אילוצים על תהליכי האינטגרציה והאימות, כגון בטיחות, תשתיות, סוגי ניסויים, יכולת מדידה וכו' אילוצים על העברת המערכת transportation( )System, כגון נפחים, אמצעי דפינה, אריזות הסעה וכו' אילוצי תפעול, כגון תרחישי ייחוס, ממשקים תפעוליים, מגבלות זמן תפעול, אבטחת נכונות הנתונים בכניסות וביציאות, רמות איוש תפעולי, ביטחון אילוצים שנובעים ממגבלות חוקיות או תקנות, מגבלות לוגיסטיות )ניקיון רכיבים( ומגבלות תהליכיות מגבלות על תחזוקת המערכת, כגון סוגי תשתיות, סוגי ציוד, רמות איוש, הכשרה מגבלות על גריטת המערכת, כגון חומרים מסוכנים, תהליכי פירוק, Reuse וכו' סוגיות לא ברורות שהתגלו בזמן ניתוח הדרישות ומסלול פתרונן תהליכי האימות והתיקוף שנדרשים על ידי הלקוח עקיבות הדרישות למקורם TBR,TBD( וכו'( ניתוח תפקודי דרישות 247

הגדרת תפקוד הגדרה "מה" שהמערכת חייבת לעשות על מנת לעמוד ב, בלי להגדיר "איך" הנתונים הנדרשים לביצוע התפקוד תהליך מימוש התפקוד תוצאות התפקוד יש להשתמש במבטים מרובים: ניתוח תרחישי ייחוס זרימה סדרתית זרימת מידע כתיבת דרישת התפקוד פעולה מתוארת ע"י פ וע ל הפועל על שם עצם, כאשר מתקיימים התנאים בהם תפקוד מתקיים הנדסת ניתוח תפקודי דרישות 248

סוגי הדרישות הלא תפקודיות הסביבה המבצעית של המערכת )תנאי סביבה בפעולה, בהמתנה, באחסון, בהובלה( דרישות ביצועים )מהירות תגובה, זמן בין נפילות, דיוק החישובים( מחזור החיים של המערכת אמינות על פי פרופיל פעולה זמינות, שעות תפעול אחזקתיות/בדיקתיות )שיטה,,BIT תשתיות, ציוד, ח"ח( בטיחות Interoperability ניקיון רכיבים שרידות דרישות תא"מ בטחון )קשר( אריזה, משלוח, אחסון, תובלה ושינוע דרישות לא תפקודיות הנדסת דרישות כ"א לניהול, הפעלה, הדרכה, תחזוקה, הובלה, דרישות הכשרה תיעוד ספרות ומסמכים שמירת הסביבה והמחזור דרישות ה- Workmanship מטריצת תיקוף המערכת דרישות הפעלה )יפעל בתנאי קרינה של חלל, ברעש אקוסטי, בקרינת שמש ישירה( דרישות ניידות )portability( ולתחזוקה מרחוק ע"י שימוש באינטרנט, תדירות החלפת גירסת מוצר( אבטחה ופרטיות: אבטחת המידע בפני וירוסים, תוכנות זדוניות וחדירה לא רצויה דרישות מראה ו"אווירה" רמת המפעיל, המתחזק, המוביל, המאחסן... דרישות חוק או רשויות )שמירת הפרטיות, גישה למידע ממשלתי, בדיקה מיוחדת ומעמיקה כמו פיקוח לכורים גרעיניים, בקרה של מיכשור רפואי( ניתוח תפקודי דרישות 249

250 סוגי דרישות הממשקים ממשקים חיצוניים פיזיים ממשקים חיצוניים לוגיים דרישות התקנה דרישות ממשקים ממשקי תוכנה פרוטוקולים, תקשורת, קודים זמני תגובה, ספיקת אותות, קצבים ממשקים אופטיים וממשקי וידאו מפתחי כניסה ויציאה, שדות ראיה ומיתוגם דרישות ייצוב ושיעבוד שיעבודים מכניים/חשמליים, דיוקים, תחומים, מהירויות ותאוצות ממשקים חשמליים אספקות, אדמות אלקטרוניקה-אותות, פרוטוקולים, תזמונים, משכים מחברים חשמליים וכבלים-מיקום, סוג, כמות פינים, סוגי פינים, יתירות, סיכוכים ממשקים אלקטרו מגנטיים- תאימות, רגישות לקליטה ופליטה לקרינה והולכה אינטרלוקים ניתוח תפקודי דרישות הנדסת ממשקים מכניים, אופטו-מכניים ואלקטרו-מכניים מידות ומשקלים, קינמטיקה )מומנטים(, דינמיקה,PSD( מגבלות תדרים עצמיים(, אטימות נקודות עגינה- מיקום, חוזק, טמפרטורה ממשקים תרמיים-העברת חום )פליטה, קרינה, קבלה(, צורת דפינה, קיבולי חום, הפרשי טמפ' ממשקי העברת נוזלים ואוויר סוגי חומרים, לחצים, תקנים, חיבורים פיזיים בקרה )סרוו( ממשקים נוספים ממשקי קרינה-צורך לעמידות בתנאי קרינה מייננת רעשים אקוסטיים תנאי סביבה, הגדרות ניקיון חלונות אופטיים והקרחתם, קושי אלמנטים אופטיים חיצוניים רגישות הסביבה לתוצרי המערכת

אופיין תפעול ממשקי אדם מכונה הנדסת אנוש דרישות תפעול הנדסת ניתוח תפקודי דרישות 251

סיווג הדרישות יש לסווג את הדרישות לפי סוגים, על מנת: להקל על זהוי קשרים, סתירות, שלמות, חוסרים, ועקביות בין הדרישות. לתכנן ולתכן פעילויות הקשורות לדרישות. לאתר דרישות הדורשות התיחסות מיוחדת, כמו דרישות בטיחות, מאפייני מפתח. לארגן את הדרישות כך שיתאימו להשקפות או קהלים שונים. לקבוע דרישות בהתאמה לאספקטים שונים בפיתוח. הנדסת ניתוח תפקודי דרישות 252

איך מאמתים דרישות )Req s Validation( בדיקה ווידוא שכל הדרישות תואמות את הנושאים הבאים: הנדסת תוקף.)Validity( האם המערכת, כפי שהוגדרה, אכן תספק את כל התפקודים הדרושים לתמיכה בצרכי הלקוח? עקביות.)Consistency( האם אין סתירות בין הדרישות? שלמות.)Completeness( האם כל התפקודים הדרושים ללקוח נכללים? בהירות.)Comprehensible( האם ניסוח הדרישות ברור וחד משמעי לכל הקוראים בר מימוש.)Realizable( האם ניתן לממש את הדרישות בתקציב, ולוחות זמנים נתונים, בטכנולוגיות נגישות? בר בדיקה.)Verifiable( האם הדרישות ניתנות לבדיקה ולתיקוף? עקיבות.)Traceable( האם מקור הדרישה ברור ורשום בבהירות? כושר הסתגלות לשינויים.)Adaptable( האם שינויים בדרישות יכולים להתבצע בלי מהפכות בקוצה גדולה של דרישות אחרות טכניקות לאימות הדרישות סקר/י דרישות - ניתוח שיטתי של הדרישות, בשיתוף הלקוחות וקבלני המשנה אבי טיפוס ומדגימים, כגון דגמים שיווקיים, מעבדות קרב וכו' יצירת תרחישי בדיקה וניתוח הבדיקתיות ניתוח תפקודי דרישות 253

הנדסת 1.3.9 הכנת מסמך הדרישות וסקר SRR ניתוח תפקודי דרישות 254

שלבי הכנת מסמך דרישות בעלי העניין )1( זיהוי בעלי העניין )Stakeholders( הכרת מגזרי הלקוח לימוד תפקידו של כל אחד מהמגזרים, מצבי הפעולה והקשרים הארגוניים הבנת השפעת המערכת המפותחת על תפקודו של הצרכן זיהוי ה הנותנים את מרב הערך ללקוח ביקור אצל מגזרי הלקוחות/בעלי העניין העיקריים מי פוי ה על פי קטגוריות זיהוי ה על פי הבקשות השונות אירגון ה למשפחות והיררכיות קביעת סדרי עדיפויות בין ה הבנת הדרישה המבצעית/צרכי בעלי העניין שיוך ה לתפקודים הראשיים שמממשים את המערכת לימוד התפקודים המשניים שמשפרים את רמת שביעות רצון הלקוח ניסוח הדרישות בצורה ברורה, חד משמעית, נוחה להבנה ושימוש של בעלי העניין הנדסת ניתוח תפקודי דרישות 255

שלבי הכנת מסמך דרישות בעלי העניין הנדסת )2( הפיכת ה לדרישות מפורטות ולפעולות לביצוע לאורך כל הפרויקט הגדרת ה מטרות התכנית סביבת הפעילות ארכיטקטורה מועדפת דרישות תפקודיות מדדים ממשקים חלופות מיפוי ה ע"פ קטגוריות: דרישות ביצועים מאפייני מפתח דרישות בטיחות דרישות נגזרות - תפקיד המערכת ברמה הגבוהה ביותר ניתוח תפקודי דרישות 256

מסמך דרישות בעלי העניין לדוגמה הנדסת Identifier Contents V&V method Requiremnt D02344 3. Non Functional Requirements No D02345 3.1 Supply Voltage No D02346 3.1.1Nominal supply voltageshoul be 28 4 V Test Mandatory D02348 3.1.2 Supply voltage ripple should be smaller or equal to 0.5 V RMS Demo Mandatory D02678 3.1.3 Supply voltage spikes should be less than 300V and their period should be less than 5 micro-second Test Safety D02679 3.1.4 Supply voltage intrreuption shoud be less than 2 second every 1 per hour or less Test Mandatory ניתוח תפקודי דרישות 257

258 סקר הדרישות SRR - System Requirements Review.1.2.3.4.5 מטרה: לבחון ולוודא כי דרישות בעלי העניין לגבי המערכת זוהו בבירור - גובשו והוגדרו בצורה מלאה ומדויקת, באופן שניתן יהיה לגזור ולגבש סופית את מפרטי המערכת לקראת שלבי ההמשך. רשימת תיוג לסקר הנדסת בחינת המתאם שבין דרישות בעלי העניין / המזמין, לבין ניסוח הדרישות הפונקציונלית על פי המוסכם בין המזמין והמבצעים הכרת הלקוחות/בעלי העניין: הצגת רשימת מגזרי בעלי העניין הפוטנציאליים של המוצר ואת הגופים המהווים בעלי העניין בכל מגזר )משתמש, מתחזק, מזמין. מוביל( ואת עיקרי ה של כל אחד מהם הכרת צרכי בעלי העניין: פירוט ניתוח ה, הצגת ניתוח ה והעדיפויות )למשל בעזרת עץ היררכי(. ניתוח ה כולל את התועלות ומשמעויותיהן ניתוח המאפיינים: פירוט המאפיינים העיקריים המגדירים את המוצר )טכניים, כספיים, לוגיסטיים, איכותיים( הצגת ההצלבה שבין המאפיינים ל פירוט המענה של ערכי היעד שנבחרו למאפיינים על צרכי בעלי העניין סדר העדיפויות בין המאפיינים מבחינת המענה לצורכי בעלי העניין תאור מידת הקושי )טכני, לו ז, עלות( בהשגת יעדים אלה :Tradeoffs זיהוי הזיקות ההדדיות בין המאפיינים לבין עצמם. הצג את הבולטים שבהם ניתוח תפקודי דרישות

הנדסת 1.3.10 מדרישות למפרטים ניתוח תפקודי דרישה מפרטים 260

מדרישה למפרט הדרישה מפרטת צורך של בעלי העניין המפרט מגדיר בשפה הנדסית את התכונות הנדרשות מהמוצר, במונחים המאפשרים פיתוח מוצלח ובדיקות המוצר הנדסת ניתוח הדרישות דרישות בעלי העניין מפרטי הפיתוח ניתוח תפקודי דרישה מפרטים 261

ניתוח הדרישות הקצאתם הנדסת ניתוח תפקודי דרישה מפרטים 262

263 שלבי הכנת מפרט הפיתוח הנדסת ניתוח הדרישות חקר ביצועים ותרגום דרישות בעלי העניין למפרטים המבוטאים בשפת המפתח, ומאפשרים פיתוח מוצלח ובדיקות המוצר וקישור דרישות אלו עם דרישות בעלי העניין שיטות אימות המפרטים Verification( )Requirements כתיבת מפרטים ותהליכי בדיקה כדי לוודא שהמערכת תוכננה נכון ועושה מה שהיא אמורה לעשות, כלומר מתאימה לדרישות המשתמש. )Bahill( וידוא כי מפרטים: נחוצים ברי בדיקה ברי השגה אינם משתמע לשני פנים מבטאים תכונה יחידה ייחודיים שלמים עקביים לא כוללים דרך מימוש ניתנים להקצאה מתומצתים כתובים בשפה סטנדרטית ניתוח תפקודי דרישה מפרטים

תפוקות דרישות מערכת + קריטרייוני אימות מפרטי המערכת מדדי אפקטיביות ונתונים שלהם תפקודי המערכת ממשקים מערכתיים עץ מפרטים מטריצת אימות דרישות מעודכנת עקיבות הדרישות תהליך ניתוח דרישות בעלי העניין בקרים )Controls( חוקים ותקנות רלוונטיים תקנים תעשייתיים הסכמים תהליכים, נוהלים והנחיות פרויקטאליים פעילויות הגדרת דרישות בעלי העניין ניתוח ותחזוקת דרישות בעלי העניין מאפשרים )Enablers( מדיניות, תהליכים ונוהלים ארגוניים תשתיות ארגוניות תשתיות פרוייקטאליות כניסות מסמכי קונספטים דרישות בעלי העניין מדדי אפקטיביות ונתונים שלהם מטריצת אימות הדרישות עקיבות הדרישות הנדסת Source: INCOSE, Systems Engineering Handbook v. 3.2.2, October 2011 ניתוח תפקודי דרישה מפרטים 264

תפוקות התהליך הנדסת דרישות המערכת דרישות מערכתיות נגזרות שנוספו בתהליך ניתוח הדרישות שנדרשות לקבלת דרישות ואילוצי הפרויקט, כולל: דרישות ביצועים Requirements( )Performance דרישות תפקודיות Requirements( )Functional דרישות לא תפקודוית Requirements( )Non Functional אילוצים ארכיטקטוניים Constraints.( )Architectural מדדי ביצוע MOPs( )Measures of Performance - ונתוניהם - הגדרת מאפייני המפתח של ביצועי המערכת שידרשו כשהמערכת תותקן ותופעל בסביבת העבודה המתוכננת רשימת תפקודי המערכת תפקודי המערכת וגבולותיה התפקודיים ממשקי מערכת תפקודיים ממשקי המערכת וחילופי המידע עם שמחוץ לגבולות התפקודיים של המערכת קריטריוני אימות מי יבצע פעילויות אימות וכן הגדרת סביבות המערכת המפותחת והציוד שנדרשים לפעילויות האימות עץ מפרטים מתבסס על האריכטורה המתפתחת מפרטים מערכתיים תוצרים של ניתוח הדרישות והארכיטקטורה המתפתחת מטריצת מעודכנת של אימות הדרישות )RVM( נתוני עקיבות דו כיווניים של הדרישות והמפרטים המערכתיים ניתוח תפקודי דרישה מפרטים 265

ניתוח אילוצי המערכת עלות לוח זמנים תהליך ניתוח הדרישות שימוש בציוד/רכיבים מסחריים COTS( )Commercial off the shelf שימוש בציוד שאינו מפותח NDI( )Non Developmental Items שימוש במתקנים קיימים ממשקים תפעוליים עם אחרות או ארגונים אחרים סביבת התפעול הנדסת ניתוח תפקודי דרישה מפרטים 266

-QFD שיטות להגדרת תכונות המוצר (Revelle et al., 1998) Quality Function Deployment זיהוי, ציפיות ודרישות הלקוח, וקישורם למוצרי החברה. Scenario-based Requirements Engineering - SCRAM (Sutcliffe, 1998) פיתוח דרישות בעזרת תסריטים, המיוצרים כך שיביעו נתיבים של התנהגויות שונות דרך.use cases Structured System Analysis and Design - SSADM (Ashworth,1990) Methodology בשלבי הניתוח והתיכון של פיתוח המערכת. מגדיר מראש את המודולים, השלבים ומטלות שיש לבצע, התוצרים והשיטות לייצור התוצרים. הנדסת ניתוח תפקודי דרישה מפרטים 267

הנדסת Quality Function 1.3.11 Deployment (QFD) ניתוח תפקודי דרישה מפרטים 268

יעדי ה- QFD QFD היא טכניקה שאפשר להשתמש בה במיוחד אם "קולו של הלקוח" אינו ברור. השיטה מספקת דרך מהירה ושיטתית לתרגום דרישות הלקוח ומידע תחרותי, למפרטים, לקבלת דרישות לרמות נמוכות יותר של תכנון ה- QFD עוסק באיסוף מידע מהלקוחות ולימוד אובייקטיבי של הנושאים הבאים מה הלקוחות רוצים באמת? מהם הציפיות של הלקוח? האם הציפיות של הלקוח יכולות לשמש להכוונת תהליך הפיתוח? מה יכולה לעשות קבוצת הפיתוח להשגת שביעות רצון הלקוחות? המידע שיאסף צריך לכלול מידע מכוון )כמו סקרי שוק, סקרי לקוחות, ניתוח מגמות שוק וכו'( מידע בלתי מכוון )כמו משובים של חוסר שביעות רצון או תביעות משפטיות( מידע סובייקטיבי )כגון שאלונים וקבוצות מיקוד( מידע על המתחרים )מי, כמה ומה נקודות החוזק שלהם( הנדסת ניתוח תפקודי דרישה מפרטים 269

הנדסת?QFD למה כן? תאום מיומנויות באירגון תומך בעבודת צוות מתאם שפות ממשקים בין דיסציפלינות מעודד את הגופים השונים לקחת אחריות מסתמך על קונצנזוס השמעה ברורה של קול הלקוח מיקוד בדרישות הלקוח אמצעי אפקטיבי להשוואה עם התחרות מתעדף את המשאבים מאפשר קביעת יעדים למוצרים בוגרים לוקח בחשבון את הגורמים החשובים לתכון המוצר מאפשר אימות הנחות וגילוי הנחות חסרות תיעוד התהליך מובנה בתוכו למה לא? השיטה איננה תהליך אוטומטי של קבלת החלטות "הבית אינו פוטר אף אחד מהאחריות לקבלת החלטות קשות" יישום לתיקון מהיר "שום דבר מזה אינו פשוט" "רעיון מבריק שנרקב בסופו של דבר בתהליך" "לא פשוט גם הוא ליצור אירגון בעל יכולת קבלת רעיונות מבריקים" עוד יותר קשה לנצל את השיטה לתפקודים חדשניים ולא מוכרים מתוך Hauser and Clausing, 1988, The House of Quality, Harvard Business Review ניתוח תפקודי דרישה מפרטים 270

עדיפויות הלקוח קורס הנדסת בית האיכות הנדסת 8 קורלציות בין המאפיינים - תפיסת הלקוחות את המתחרים 4 מאפיינים הנדסיים - ה איך זיקות בין צורכי הלקוחות והמאפיינים הלקוחות צורכי המה 1 5 2 3 6 7 9 החשיבות היחסית של המאפיינים הערכת ביצועי המתחרים ערכי יעד למאפיינים ניתוח תפקודי דרישה מפרטים 271

מה" קורס הנדסת בניית בית האיכות הכנת רשימת דרישות הלקוח )ה- "( ותיעדופם רשימת המאפיינים הטכניים )ה-"איך"( ניתוח היחסים בין ה-"מה" וה-"איך" ניתוח הקשרים בין המאפיינים השונים )ה-"איך"( הערכת החשיבות היחסית של המאפיינים הטכניים בעיני הלקוח הערכת תפיסת התחרות בעיני הלקוח הערכת ערכי המאפיינים הטכניים כתוצאה מניתוחים אלו הנדסת ניתוח תפקודי דרישה מפרטים 272

Customer Requirements (WHATs) Primary Secondary קורס הנדסת הנדסת L - Shaped Diagram Primary Technical Descriptors (HOWs) Secondary ניתוח תפקודי דרישה מפרטים 273

Customer Requirements (WHATs) Primary Secondary קורס הנדסת הנדסת Relationship Matrix Primary Technical Descriptors (HOWs) Secondary Relationship between Customer Requirements and Technical Descriptors WHATs vs. HOWs +9 +3 +1 Strong Medium Weak ניתוח תפקודי דרישה מפרטים 274

Customer Requirements (WHATs) Primary Secondary קורס הנדסת הנדסת Correlation Matrix Primary Secondary Technical Descriptors (HOWs) Interrelationship between Technical Descriptors (correlation matrix) HOWs vs. HOWs +9 +3-3 -9 Strong Positive Positive Negative Strong Negative Relationship between Customer Requirements and Technical Descriptors WHATs vs. HOWs +9 +3 +1 Strong Medium Weak ניתוח תפקודי דרישה מפרטים 275

Customer Competitive Assessment Ours A s B s Customer Requirements (WHATs) קורס הנדסת הנדסת Customer Competitive Assessment 5 3 1 2 5 1 4 4 Relationship between Customer Requirements and Technical Descriptors WHATs vs. HOWs +9 +3 +1 Strong Medium Weak ניתוח תפקודי דרישה מפרטים 276

Customer Competitive Assessment Ours A s B s Customer Requirements (WHATs) קורס הנדסת הנדסת Tecnichal Competitive Assessment Technical Competitive Assessment Our A s B s 1 3 4 2 1 2 1 4 5 3 1 2 5 1 4 4 Relationship between Customer Requirements and Technical Descriptors WHATs vs. HOWs +9 +3 +1 Strong Medium Weak ניתוח תפקודי דרישה מפרטים 277

Prioritized Customer Requirements Importance Rating Target Value Scale-Up Factor Sales Point Absolute Weight & Percent (Importance Rating) (Scale-Up Factor) (Sales Point) קורס הנדסת הנדסת ניתוח תפקודי דרישה מפרטים 278

Customer Competitive Assessment Ours A s B s Customer Importance Target Value Scale-up Factor Sales Point Absolute Weight Customer Requirements Prioritized Customer Requirements Primary Secondary קורס הנדסת הנדסת Prioritized Customer Requirements Primary Technical Descriptors Secondary Technical Competitive Assessment Our A s B s 1 3 4 2 1 2 1 4 5 3 1 2 5 1 4 4 7 3 9 10 2 4 8 1 5 3 2 3 5 2 4 4 1.5 1 1.2 1.5 1 1 1.5 1 1.5 1 15 3 Relationship between Customer Requirements and Technical Descriptors WHATs vs. HOWs +9 +3 +1 Strong Medium Weak ניתוח תפקודי דרישה מפרטים 279

הנדסת Prioritized Technical Descriptors Degree Of Difficulty Target Value Absolute Weight & Percent n a j 1R ij c i i R is Relationship Matrix c is Customer Importance Relative Weight & Percent b j n R i 1 ij d i R is Relationship Matrix d is Customer Absolute Weights ניתוח תפקודי דרישה מפרטים 280

Customer Competitive Assessment Our A s B s Customer Importance Target Value Scale-up Factor Sales Point Absolute Weight Customer Requirements Prioritized Customer Requirements Primary Secondary קורס הנדסת הנדסת The Complete Quality House Interrelationship between Technical Descriptors (correlation matrix) HOWs vs. HOWs +9 +3-3 -9 Strong Positive Positive Negative Strong Negative Technical Competitive Assessment Primary Secondary Technical Descriptors Degree of Technical Difficulty 1 8 4 2 9 8 2 5 Target Value 2 3 4 3 1 3 1 5 Absolute Weight and Percent 90 Relative Weight and Percent 133 Prioritized Technical Descriptors Our A s B s 1 3 4 2 1 2 1 4 Relationship between Customer Requirements and Technical Descriptors WHATs vs. HOWs 5 3 1 2 5 1 4 4 7 3 9 10 2 4 8 1 +9 +3 +1 5 3 2 3 5 2 4 4 1.5 1 Strong Medium Weak 1.2 1.5 1 1 1.5 1 1.5 1 15 3 281

הנדסת קורס הנדסת דוגמה - מזגן: עץ צורכי הלקוח 282 מיזוג אוויר בחדר מגורים צורך ראשי ניתוח תפקודי משתמעים מחמם ומקרר מהר קל ופשוט להפעלה אמין זול להפעלה שקט קל לתחזוקה, או ללא תחזוקה לא תופס מקום בחדר בטיחותי אסתטי שירות טוב דרישה מפרטים רב עוצמה חימום וקירור הפעלה מהירה מעט כפתורים סימון ברור וקריא קל למצוא גם בלילה מפזר אוויר באופן אוטומטי לאורך זמן בתנאי גשם וכפור בתנאי קיץ יציאת אוויר רחבה קומפרסור יעיל ושקט פירוק והרכבה פשוטים של הפילטר חלקי חילוף זמינים ותקניים שימוש בכלי עבודה סטנדרטיים קטן תלוי גבוה לא מחשמל לא תופס אצבעות בלי פינות חדות מראה אסתטי עיצוב מודרני הדרכת צוות התקנה ותחזוקה הכנת תיעוד להתקנה ואחזקה 1

טכניקת NGT לקביעת חשיבות צורכי הלקוח של מזגן הנדסת 2 Nominal Group Technique -חשיבות צרכי הלקוח החלטה )0-5( 2 רחל 1 3 מיכל 1 צורך לקוח משקל שושנה שלום- מ' פרוייקט נתן- מ' מחלקה עדי- מ' מערכת ממוצע סטית תקן 3 1 משה 1 יעקב 1 4 11.8 22.3 16 15 10 13 16 10 11 1 מחמם ומקרר מהר 19 2 10.3 15.9 9 5 12 14 10 10 3 2 קל ופשוט להפעלה 11 5 22.4 31.6 20 28 28 18 15 25 10 3 זול להפעלה 3 4 13.1 23.3 14 18 17 7 12 8 22 16 4 אמין 3 11.0 18.0 12 15 8 4 14 20 5 10 5 שקט 2 10.4 13.6 5 4 4 3 13 6 20 15 6 תחזוקתי 1 4.0 6.3 3 3 2 2 5 4 3 7 לא תופס מקום בחדר 11 3 11.8 20.3 15 10 15 17 9 2 18 13 8 בטיחותי 2 6.3 11.4 6 2 4 22 6 15 8 2 9 אסתטי 100 100 100 100 100 100 100 100 מתוך : 2001 Laskey, Idea Generation: Nominal Group Technique, Kathryn Blackmond ניתוח תפקודי דרישה מפרטים 283

עדיפויות הלקוח קורס הנדסת בית האיכות של מזגן הנדסת 8 קורלציות בין המאפיינים 5 2 3 284 תפיסת הלקוחות את המתחרים 6 7 9 8 6 7 9 9 9 8 8 8 7 7 5 8 7 9 8 6 8 8 9 8 7 8 7 8 9 5 7 8 9 9 9 6 8 7 7 9 מאפיינים הנדסיים "איך" - ה החשיבות היחסית של המאפיינים הערכת ממוצע ביצועי המתחרים הערכת ביצועי המתחרה BIC ערכי יעד למאפיינים 1 6 7 8 9 4 צרכי הלקוחות מחמם ומקרר מהר קל ופשוט להפעלה זול בהפעלה אמין שקט תחזוקתי בטיחותי אסתטי ה"מה" 2 4 5 4 3 2 3 2 We F E T A Best in class (BIC) ניתוח תפקודי דרישה מפרטים

מדחס חזק )1.5 כ"ס( מדחס סיבובי )600 RPM, 25dB( מעבה מכני )1 כ"ס( אלקר' ספרתית )2 שורות תצוגה( מד טמפ' אוויר מדויק )1 מעלה( מבנה מודולארי כיסוי מחומר מרוכב בידוד אקוסטי מעולה )-10dB( הנדסת 1 a j 1R ij c i b j 6 7 9 n i n R i 1 ij d 4 מאפיינים הנדסיים - ה איך 8 קורס הנדסת 5 זיקות בין צורכי הלקוחות והמאפיינים בית האיכות של מזגן קורלציות בין המאפיינים מחמם ומקרר מהר קל ופשוט להפעלה זול בהפעלה אמין שקט תחזוקתי בטיחותי אסתטי החשיבות היחסית של המאפיינים הערכת ממוצע ביצועי המתחרים הערכת ביצועי המתחרה BIC ערכי יעד למאפיינים i 38 120 138 81 205 234 30 90 108 87 224 240 1.5 20dB כ"ס 1 LCD 27 44 51 54 133 153 42 118 114 42 94 105 5dB -פלסטיקמודולרי ±2º 2 2 4 5 4 3 2 3 2 +9 +3 6 7 9 8 8 8 7 6 +1 We 7 9 9 7 8 7 8 8 F חזקה בינונית חלשה 3 9 8 8 9 9 8 9 7 E 8 8 7 8 8 9 9 7 T 6 7 5 6 7 5 9 9 A Best in class (BIC) 285

סיכום ה- QFD דרך מסודרת לקבלת המידע והצגתו מחזור פיתוח מוצר נכון יותר ולכן קצר יותר חסכון בשגיאות גורם להפחתת עלויות הפיתוח במידה ניכרת פחות שינויים הנדסיים סיכוי מופחת לאי התייחסות לגורמים חשובים בתהליך הפיתוח כאמור, מעודד עבודת צוות תוך נטילת מחויבויות בהתאם קבלת החלטות בקונצנזוס תיעוד מובנה של תהליך בחירת המאפיינים הנדסת ניתוח תפקודי דרישה מפרטים 286

הנדסת 1.3.12 רידוד דרישות ניתוח תפקודי דרישה מפרטים 287

רידוד הדרישות הנדסת חשיבות הדרישה )לדוגמה ) QFD גבוהה מאד לאתגר לקבל הכל לבטל לשקול לבטל נמוכה מאד עלות מימוש הדרישה )לדוגמה )DTC גבוהה מאד ניתוח תפקודי מקור: דרישה איציק בן לוי www.benlevi.co.il מפרטים נמוכה מאד 288

הורדת עלויות המוצר היכן כדאי להשקיע מאמץ? הנדסת כיפופי ידים לספקים או רידוד דרישות התכן ניתוח תפקודי מקור: דרישה איציק בן לוי www.benlevi.co.il מפרטים 289

הנדסת 1.3.13 הכנת המפרטים ניתוח תפקודי דרישה מפרטים 290

דוגמה לעץ מפרטים מסמך דרישות בעלי העניין CRD הנדסת System Spec. SRD Operational Spec. Functional Spec. EU S/W requierments Spec. SRS DU S/W requierments Spec. SRS EU Spec. SSRD GU Spec. SSRD DU Spec SSRD EU Power Supply Spec. EU Logic CCU Spec. ניתוח תפקודי דרישה מפרטים 291

הנדסת Requirement Identifier קורס הנדסת מבנה מפרט הפיתוח מפרט המוצר הוא תיאור מדויק של מה המוצר אמור לעשות רשימה של דרישות טכניות לפיתוח )להבדיל מדרישות בעלי העניין(. דוגמא: Contents 3. Non Functional D02344 Requirements D02345 3.1 Supply Voltage 3.1.1Nominal supply voltage D02346 should be 28 4 VDC 3.1.2 Supply voltage ripple D02348 should be smaller or equal to 0.5 V RMS 3.1.3 Supply voltage spikes level should be less than D02678 300V and their period should be less than 5 microsecond (FWHM) 3.1.4 Supply voltage intrreuption shoud be less D02679 than 2 second every 1 per hour or less No No Discipline Power Mandatory Electronics Power Mandatory Electronics Safety Power Electronics System Units PSU PSU PSU Power PSU, Mandatory Electronics LGU V&V method Test Demo Test Test Comply Yes Yes Partially Yes Notes Depends on volume restrictions ניתוח תפקודי דרישה מפרטים 292

הנדסת ניהול מאפייני מפתח Key Characteristics( ) מפרט פיתוח לדוגמה Comments Need to make sure light budget is sufficient. Need to improve auto focus scenario Need to improve optical head lifetime Comply Risky Risky Risky Subsystem All Focus, optical head, motion All Active Discipline Algorithms SW Physics Electronics Mechanics System Physics Mechanics System Electronics Physics System Req KC KC KC System shall scan 100 panels / hour Image shall be always in focus System MTBF shall be >100 days ID 87 334 360 ניתוח תפקודי דרישה מפרטים 293

קביעת קונספט המערכת, תיכון מערכתי והכנה ל- SDR ניתוח תפקודי Analysis(,)Functional ניתוח סיכונים והגדרה ראשונית של המערכת. סינטזה ובחינת חלופות מערכתיות ובחירת הפתרון המתאים ביותר בדיקת התאמת התיכון המערכתי לצרכי בעלי העניין, לסביבה המערכתית וליעדי התוכנית. בדיקת אפשרויות Reuse ו/או תכן גנרי ביצוע מטלות בטיחות תכנון ראשוני של מהלך האינטגרציה עידכון את מסמך בקרת הממשקים )ICD( המערכתי )החיצוני( עידכון את מפרטי הפיתוח הקצאה ראשונית של מפרטי פיתוח למכללים הנדסת ניתוח תפקודי דרישה מפרטים 294

הנדסת 295